В прошлой статье мы рассмотрели процесс установки kvm на CentOS 6.2. Установка велась в текстовом режиме, чтобы имея доступ по ssh не городить лишний огород с запуском графической системы и проброской её до компьютера администратора (или подключением по vnc).
Для установки использовался обычный файл хост-системы, который kvm предоставлял гостю как дисковое устройство. Несмотря на то что по умолчанию используется virtio-драйвер (а значит паравиртуализация для устройства), производительность схемы с файлом снижается по сравнению с обычным устройством теоретически хотя бы потому что дублируются функции файловой системы (гость создаёт свою файловую систему, которая работает как бы "поверх" файловой системы хоста). Практика подтверждает потери производительности. А хотелось бы не терять зачастую столь необходимую производительность подсистемы ввода-вывода (вв).
Однако, выход из этой ситуации есть - нужно "пробрасывать" гостю "сырые" дисковые разделы которые есть в хост-системе (разделы, конечно, специально для того созданные). Согласно документации, такая схема позволяет почти полностью избежать потерь производительности связанных с дисковым вв.
То что наша система установлена в файл, гипотетически, не должно снижать производительность гостевой системы т.к. вв на корневом разделе практически отсутствует (исключения составляют логи, но их я намереваюсь направлять на отдельный сервер из соображений безопасности).
В данной статье я расскажу как подключить lvm-раздел хост-системы напрямую к гостевой системе (lvm - сокращение от Logical Volume Manager - менеджер логических томов, документация на русском есть тут http://xgu.ru/wiki/Lvm , ну и у вас всегда есть man) . Этот подход позволяет сочетать гибкость, которую предоставляет lvm (например, динамическое изменение размера раздела и мнгновенные снимки, которые на мой взгляд, удобны для резервного копирования) и скорость, которую предоставляет паравиртуализация.
Вся наша работа сводится к 3 шагам:
1) Создание lvm-разделов.
2) Подключение lvm-раздела к виртуальной машине средствами virsh.
3) Работа с новым устройством внутри гостевой ОС. Подключение дополнительного диска без перезагрузки гостевой ОС (горячее подключение, hot plug).
Итак, приступим.
Предварительное требование - у вас должен быть свободный раздел. Если у вас что-то смонтировано в /home например, то отмонтируйте, отрежьте и подмонтируйте /home обратно (если надо). Если у вас единственный раздел на котором есть свободное место подмонтирован к корню, то изменить его размер (т.е. отрезать от него что-то) без физического доступа к системе Вы не сможете. По крайней мере мне не известно как это сделать. У меня была именно такая ситуация (весь диск смонтирован в /), поэтому я попросил службу поддержки хостинга переустановить систему, используя в качестве корневого раздел размером 15Гб. Остальную часть диска (порядка 450Гб) инженер поддержки подмонтировал в /home, откуда я эту часть успешно отключил и разметил. Если отмонтируете раздел насовсем, не забудьте убрать запись из fstab.
Шаг 1. Создание lvm-разделов.
Предполагаем, что у вас есть свободное отмонтированное устройство (или раздел), которое вы будете использовать на этом шаге чтобы создать lmv-тома.
Первое, что скорее всего необходимо сделать - это прикинуть, сколько в будущем вы будете настраивать виртуальных машин и сколько места они будут занимать. И сколько места будут занимать текущие виртуальные машины. Прикидка нужна для того чтобы оставить достаточно свободного места. Не бойтесь оставить слишком много места. LVM позволяет без всяких затруднений добавить место к текущему разделу в дальнейшем. А файловые системы (в основном по карайней мере... а ext4 которую мы будем использовать - точно) легко расширяются, чего нельзя сказать об урезании (например, xfs вообще не позволяет уменьшать размер фс).
Для примера моя ситуация: я планирую один mysql-сервер, два web-сервера и один лог-сервер. Один из веб-серверов будет обслуживать сайт "весом" как минимум 70Гб. Ему я выделил 140Гб. Второй веб-сервер для wordpress-хостинга, скорее всего не более 10 сайтов, т.е. 5Гб места ему хватит "с головой". Для MySQL мне достаточно будет 1Гб, но я выделю ему 3 "прозапас". Для логов (по опыту) мне надо порядка 5Гб места. Выделим 10Гб. Итого у меня будет 4 раздела - 140Гб, 5Гб, 3Гб, 10Гб (всего 158Гб) и останется около 300Гб неиспользованного пространства. Мой свободный раздел зовётся /dev/sda5. Его размер 448Гб
Для тех, кто мало зноком с LVM. Во первых, ещё раз рекомендую документацию на xgu.ru. Во вторых, вкратце объясняю, что мы сейчас будем делать:
а) создадим физический том lvm на /dev/sda5. Шаг необходим для того чтобы добавить наш диск как источник в группу томов.
б) создадим группу томов и добавим в неё наш раздел. Именно на базе группы томов создаются логические разделы которые мы будем использовать. После этого LVM сможет использовать группу томов (к которой как источник свободного места подключён наш раздел) для выделения места логическим томам, которые мы в итоге и будем "пробрасывать" гостям.
в) создадим логические разделы (тома), которые будем "пробрасывать" гостям.
Делаем. (Если что-то не удаётся, ещё раз отсылаю к документации на xgu.ru. Ну или в комменты, может чем помогу.)
а) во-первых установите программой fdisk тип раздела Linux LVM (номер 8e в списке fdisk) для /dev/sda5;
во-вторых:
Как можно видеть, физический том успешно создан. На утечку дескриптора предлагаю закрыть глаза. Далее.
б)
Как видно, группа томов VGMainSpace успешно создана. Едем дальше.
в) создаём логические тома LVbigsite, LVwordpress, LVdb и LVlogs.
Как видите, с первым шагом мы успешно справились. Можно выдохнуть. Впереди шаги 2 и 3, но они сильно проще, занимают меньше времени при чтении/описании и/или более знакомы администраторам (это я про работу с разделом внутри гостевой ОС).
Шаг 2. Подключение lvm-раздела к виртуальной машине средствами virsh.
Это просто.
Вместо try14 вводите свой идентификатор машины. /dev/mapper/VGMainSpace-LVdb - это путь к lvm-разделу. vdb - свободный идентификатор диска внутри гостевой ОС. vda у вас будет занят по умолчанию скорее всего. Следующий, соответственно, vdb. Замечание: к названию тома (LVdb) идентификатор диска (vdb) отношения не имеет, просто так совпало что и то и другое у меня оканчивается на db.
Для проверки того что у вас получилось сделайте из virsh dumpxml:
Вы должны увидеть в xml-конфигурации свой новый диск. Мой, к примеру, выглядит так:
На этом шаг 2 успешно завершён.
Шаг 3. Работа с новым устройством внутри гостевой ОС. Подключение дополнительного диска без перезагрузки гостевой ОС (горячее подключение, hot plug).
Первое, и наверное, самое любопытное, это горячее подключение. Осуществить это сильно проще чем звучит. Подключаетесь по ssh к гостевой ОС и делаете следующее:
Затем смотрите в dmesg:
Если видите примерно то же что у меня, то
Ваш желанный диск на месте.
Далее создаём на нём раздел с помощью fdisk и затем файловую систему:
Монтируем куда хотим и работаем дальше.
Если вам вдруг не нужно горячее подключение (или оно не сработало, что вообще говоря странно), просто перезагрузите гостевую ОС.
Шаг 3 на этом закончился. Как и вся статья.
Спасибо за внимание.
Для установки использовался обычный файл хост-системы, который kvm предоставлял гостю как дисковое устройство. Несмотря на то что по умолчанию используется virtio-драйвер (а значит паравиртуализация для устройства), производительность схемы с файлом снижается по сравнению с обычным устройством теоретически хотя бы потому что дублируются функции файловой системы (гость создаёт свою файловую систему, которая работает как бы "поверх" файловой системы хоста). Практика подтверждает потери производительности. А хотелось бы не терять зачастую столь необходимую производительность подсистемы ввода-вывода (вв).
Однако, выход из этой ситуации есть - нужно "пробрасывать" гостю "сырые" дисковые разделы которые есть в хост-системе (разделы, конечно, специально для того созданные). Согласно документации, такая схема позволяет почти полностью избежать потерь производительности связанных с дисковым вв.
То что наша система установлена в файл, гипотетически, не должно снижать производительность гостевой системы т.к. вв на корневом разделе практически отсутствует (исключения составляют логи, но их я намереваюсь направлять на отдельный сервер из соображений безопасности).
В данной статье я расскажу как подключить lvm-раздел хост-системы напрямую к гостевой системе (lvm - сокращение от Logical Volume Manager - менеджер логических томов, документация на русском есть тут http://xgu.ru/wiki/Lvm , ну и у вас всегда есть man) . Этот подход позволяет сочетать гибкость, которую предоставляет lvm (например, динамическое изменение размера раздела и мнгновенные снимки, которые на мой взгляд, удобны для резервного копирования) и скорость, которую предоставляет паравиртуализация.
Вся наша работа сводится к 3 шагам:
1) Создание lvm-разделов.
2) Подключение lvm-раздела к виртуальной машине средствами virsh.
3) Работа с новым устройством внутри гостевой ОС. Подключение дополнительного диска без перезагрузки гостевой ОС (горячее подключение, hot plug).
Итак, приступим.
Предварительное требование - у вас должен быть свободный раздел. Если у вас что-то смонтировано в /home например, то отмонтируйте, отрежьте и подмонтируйте /home обратно (если надо). Если у вас единственный раздел на котором есть свободное место подмонтирован к корню, то изменить его размер (т.е. отрезать от него что-то) без физического доступа к системе Вы не сможете. По крайней мере мне не известно как это сделать. У меня была именно такая ситуация (весь диск смонтирован в /), поэтому я попросил службу поддержки хостинга переустановить систему, используя в качестве корневого раздел размером 15Гб. Остальную часть диска (порядка 450Гб) инженер поддержки подмонтировал в /home, откуда я эту часть успешно отключил и разметил. Если отмонтируете раздел насовсем, не забудьте убрать запись из fstab.
Шаг 1. Создание lvm-разделов.
Предполагаем, что у вас есть свободное отмонтированное устройство (или раздел), которое вы будете использовать на этом шаге чтобы создать lmv-тома.
Первое, что скорее всего необходимо сделать - это прикинуть, сколько в будущем вы будете настраивать виртуальных машин и сколько места они будут занимать. И сколько места будут занимать текущие виртуальные машины. Прикидка нужна для того чтобы оставить достаточно свободного места. Не бойтесь оставить слишком много места. LVM позволяет без всяких затруднений добавить место к текущему разделу в дальнейшем. А файловые системы (в основном по карайней мере... а ext4 которую мы будем использовать - точно) легко расширяются, чего нельзя сказать об урезании (например, xfs вообще не позволяет уменьшать размер фс).
Для примера моя ситуация: я планирую один mysql-сервер, два web-сервера и один лог-сервер. Один из веб-серверов будет обслуживать сайт "весом" как минимум 70Гб. Ему я выделил 140Гб. Второй веб-сервер для wordpress-хостинга, скорее всего не более 10 сайтов, т.е. 5Гб места ему хватит "с головой". Для MySQL мне достаточно будет 1Гб, но я выделю ему 3 "прозапас". Для логов (по опыту) мне надо порядка 5Гб места. Выделим 10Гб. Итого у меня будет 4 раздела - 140Гб, 5Гб, 3Гб, 10Гб (всего 158Гб) и останется около 300Гб неиспользованного пространства. Мой свободный раздел зовётся /dev/sda5. Его размер 448Гб
Для тех, кто мало зноком с LVM. Во первых, ещё раз рекомендую документацию на xgu.ru. Во вторых, вкратце объясняю, что мы сейчас будем делать:
а) создадим физический том lvm на /dev/sda5. Шаг необходим для того чтобы добавить наш диск как источник в группу томов.
б) создадим группу томов и добавим в неё наш раздел. Именно на базе группы томов создаются логические разделы которые мы будем использовать. После этого LVM сможет использовать группу томов (к которой как источник свободного места подключён наш раздел) для выделения места логическим томам, которые мы в итоге и будем "пробрасывать" гостям.
в) создадим логические разделы (тома), которые будем "пробрасывать" гостям.
Делаем. (Если что-то не удаётся, ещё раз отсылаю к документации на xgu.ru. Ну или в комменты, может чем помогу.)
а) во-первых установите программой fdisk тип раздела Linux LVM (номер 8e в списке fdisk) для /dev/sda5;
во-вторых:
# pvcreate /dev/sda5 File descriptor 7 (pipe:[24162]) leaked on pvcreate invocation. Parent PID 6323: bash Writing physical volume data to disk "/dev/sda5" Physical volume "/dev/sda5" successfully created
#
Как можно видеть, физический том успешно создан. На утечку дескриптора предлагаю закрыть глаза. Далее.
б)
# vgcreate VGMainSpace /dev/sda5 File descriptor 7 (pipe:[24162]) leaked on vgcreate invocation. Parent PID 6323: bash Volume group "VGMainSpace" successfully created
Как видно, группа томов VGMainSpace успешно создана. Едем дальше.
в) создаём логические тома LVbigsite, LVwordpress, LVdb и LVlogs.
# lvcreate -L140G -nLVbigsite VGMainSpace File descriptor 7 (pipe:[24162]) leaked on lvcreate invocation. Parent PID 6323: bash Logical volume "LVbigsite" created # lvcreate -L5G -nLVwordpress VGMainSpace File descriptor 7 (pipe:[24162]) leaked on lvcreate invocation. Parent PID 6323: bash Logical volume "LVwordpress" created # lvcreate -L3G -nLVdb VGMainSpace File descriptor 7 (pipe:[24162]) leaked on lvcreate invocation. Parent PID 6323: bash Logical volume "LVdb" created # lvcreate -L10G -nLVlogs VGMainSpace File descriptor 7 (pipe:[24162]) leaked on lvcreate invocation. Parent PID 6323: bash Logical volume "LVlogs" created #
Как видите, с первым шагом мы успешно справились. Можно выдохнуть. Впереди шаги 2 и 3, но они сильно проще, занимают меньше времени при чтении/описании и/или более знакомы администраторам (это я про работу с разделом внутри гостевой ОС).
Шаг 2. Подключение lvm-раздела к виртуальной машине средствами virsh.
Это просто.
# virsh virsh # attach-disk try14 /dev/mapper/VGMainSpace-LVdb vdb --sourcetype block --persistent Диск подключен успешно
#
Вместо try14 вводите свой идентификатор машины. /dev/mapper/VGMainSpace-LVdb - это путь к lvm-разделу. vdb - свободный идентификатор диска внутри гостевой ОС. vda у вас будет занят по умолчанию скорее всего. Следующий, соответственно, vdb. Замечание: к названию тома (LVdb) идентификатор диска (vdb) отношения не имеет, просто так совпало что и то и другое у меня оканчивается на db.
Для проверки того что у вас получилось сделайте из virsh dumpxml:
virsh # dumpxml try14
Вы должны увидеть в xml-конфигурации свой новый диск. Мой, к примеру, выглядит так:
- <disk type='block' device='disk'>
- <driver name='qemu' type='raw'/>
- <source dev='/dev/mapper/VGMainSpace-LVdb'/>
- <target dev='vdb' bus='virtio'/>
- <alias name='virtio-disk1'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
- </disk>
На этом шаг 2 успешно завершён.
Шаг 3. Работа с новым устройством внутри гостевой ОС. Подключение дополнительного диска без перезагрузки гостевой ОС (горячее подключение, hot plug).
Первое, и наверное, самое любопытное, это горячее подключение. Осуществить это сильно проще чем звучит. Подключаетесь по ssh к гостевой ОС и делаете следующее:
# echo 1 > /sys/bus/pci/rescan
Затем смотрите в dmesg:
# dmesg | tail virtio-pci 0000:00:07.0: irq 33 for MSI/MSI-X vdb: unknown partition table
Если видите примерно то же что у меня, то
# ls /dev/vdb /dev/vdb
Ваш желанный диск на месте.
Далее создаём на нём раздел с помощью fdisk и затем файловую систему:
# mkfs.ext4 /dev/vdb1
Монтируем куда хотим и работаем дальше.
Если вам вдруг не нужно горячее подключение (или оно не сработало, что вообще говоря странно), просто перезагрузите гостевую ОС.
Шаг 3 на этом закончился. Как и вся статья.
Спасибо за внимание.
А возможен одновременный доступ к подключенному диску из гостевой и хост системы одновременно?
ОтветитьУдалитьне уверен, но скорее всего нет. Вопрос в том позволяет ли это делать lvm или нет. Тут надо смотреть документацию.
Удалить