illumium.org

Виртуальные машины, вне всяких сомнений, очень важная и полезная вещь для разработчика приложений. Чтобы поддерживать в своих продуктах широкий спектр платформ, без тестирования и отладки кода на всех них вряд ли как-то обойтись. Особенно это актуально при создании WEB-приложений, способных работать в различных браузерах и их версиях на многих операционных системах.

Речь пойдёт об использовании в целях виртуализации Qemu или Kvm, лучшего по мнению автора решения для виртуализации.

Почему Qemu

Мне приходилось иметь дело с различными виртуальными машинами, не буду описывать их достоинства и недостатки, расскажу здесь о том, почему лучшим выбором для меня является Qemu или Kvm.

Qemu весьма продвинутая в плане возможностей вещь, вместе с тем довольно таки простая и послушная в управлении.

Работа с образами

Родной формат образов жестких дисков Qemu называется Qcow2. Образ в данном формате имеет нефиксированный размер, увеличивающийся в процессе выполнения операций записи. Технология работает на «железном» по отношению к гостевой операционной системе уровне, поэтому никак не ограничивает выбор файловых систем.

Многие люди не используют Qcow2 поскольку raw образы можно монтировать базовыми средствами и работать с ними напрямую. Однако, образы Qcow2 тоже можно монтировать с использованием модуля ядра nbd.

Снимки (Snapshots)

Эта особенность связана с устройством Qcow2 и заключается в возможности зафиксировать некий образ в текущем состоянии, а дальнейшие изменения производить уже в другой постоянный или временный образ.

Снимки оказались для меня очень полезной вещью, которая позволила кардинально решить проблему занимаемого образами виртуалок места. Теперь вместо десятков гигабайт у меня всего два с небольшим занято под снэпшоты с различными конфигурациями, с одним базовым образом.

Различные архитектуры

Qemu умеет эмулировать, наверно, самый обширный спектр аппаратных архитектур среди всех прочих виртуальных машин. На нём, кстати, запускаются образы мобильных операционных систем. Например, в средствах разработки для Android самизнаетекого.

С другой стороны, сам Qemu способен работать на не меньшем числе аппаратных архитектур и операционных систем в том числе на мобильных устройствах, как бы это ни «ломало» для некоторых «шаблон».

Нескучная практическая часть

Достоинства Qemu можно перечислять долго, так что самое время перейти к практике.

Создание базового образа

Итак, нет ничего проще:

$ qemu-img create -f qcow2 base.qcow2 10G
Formatting 'test.qcow2', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536
$ du -skh test.qcow2
136K	test.qcow2

Мы создали образ base.qcow2, который может иметь максимальный размер 10G. Однако, пока он пуст и занимает всего 136K места в нашей файловой системе.

Если у нас нет уже готового образа нужной нам операционной системы в самом что ни на есть девственном виде, то придётся сделать его самостоятельно, взяв имеющийся образ с установщиком:

$ kvm -m 512M -hda base.qcow2 -cdrom guess.iso -boot d

Здесь я использовал команду kvm вместо qemu, потому что в моём дистрибутиве таким образом задействуется функционал виртуализации ядра, ускоряющий работу виртуальной машины с аналогичной хост-системе архитектурой.

Виртуальная машина загрузит установщик с образа guess.iso, которому будет доступен наш базовый образ base.qcow2. Я выделил машине 512M оперативной памяти, а опция -boot с параметров d заставляет загружаться с устройства cdrom. Делаем там всю грязную работу по установке операционной, или вообще находим готовый подходящий образ в «доверенном источнике».

Тюнинг гостевой системы

На самом деле у меня уже были готовые образы, поэтому далее требовалось только несколько подшаманить с ними в плане улучшения, так сказать, эксплуатационных характеристик.

Главное, что нужно сделать, это отучить операционку срать ненадлежащим образом использовать наш образ. Отключаем все возможные свопы/подкачки/или что там у вас, временные каталоги типа /tmp переводим куда-нибудь в другой раздел.

Например, можно создать отдельный образ temp.qcow2 аналогично базовому, а затем подключить его как второй винчестер:

$ qemu-img create test-temp.qcow2 1G
Formatting 'test-temp.qcow2', fmt=raw size=1073741824
$ kvm -m 512M -hda base.qcow2 -hdc temp.qcow2

Теперь форматируем новый образ в гостевой системе, подключаем и переводим туда все склонные к избытку холестерина каталоги.

Если сравнить объём занятого операционной системой места с объёмом образа, то почти наверняка последний будет больше где-то порядка на 15-25%. Это нормально, но суровые оптимизаторы обязаны это недоразумение исправить. Я просто создал ещё один такой же пустой базовый образ, отформатировал его в гостевой операционной системе и скопировал все файлы с исходного образа, после чего установил на него системный загрузчик. Новый образ получился уже значительно меньше предшественника, пробуем загрузиться с него, если всё в порядке, то первоначальный можно упокоить с миром.

Подключение образа Qcow2

С копированием файлов то всё понятно, а вот с переносом загрузчика бывает далеко не всё так просто, а зачастую самым тривиальным решением может оказаться использование dd. Это первый случай, когда нам может потребоваться работать с образом гостевой системы как с устройством.

Нам потребуется модуль ядра nbd:

$ sudo modprobe nbd max_part=12
$ ls -al /dev/nbd*
brw-rw---T 1 root disk 43,   0 Май 31 22:36 /dev/nbd0
…

Так мы подключили модуль, затребовав 12 разделов, готовых к связыванию с конечными сетевыми устройствами. Теперь осталось превратить наш образ в одно из таких устройств и подключить к одному из разделов:

$ sudo qemu-nbd -c /dev/nbd0 $PWD/base.qcow2
$ ls -al /dev/nbd0*
brw-rw---T 1 root disk 43, 0 Май 31 23:05 /dev/nbd0
brw-rw---T 1 root disk 43, 1 Май 31 23:05 /dev/nbd0p1

Как видим, появилось ещё одно устройство, это наш первичный раздел, можно делать с ними обоими, как если бы они были обычными устройствами, вот так просто это работает, и никаких петель. Например, просто примонтируем файловую систему первичного раздела:

$ mkdir base
$ sudo mount /dev/nbd0p1 base

Отключить образ можно, когда все его разделы отмонтированы, командой:

$ sudo qemu-nbd -d /dev/nbd0 
/dev/nbd0 disconnected
$ ls -al /dev/nbd0*
brw-rw---T 1 root disk 43, 0 Май 31 23:05 /dev/nbd0

Устройство снова одно.

Особенности крионики снимков

Когда базовый образ готов, самое время его «заморозить». Делаем его доступным только для чтения, ведь больше мы его менять никогда не будем. Теперь создадим новый образ, но совсем не такой как раньше:

$ qemu-img create -f qcow2 -b base.qcow2 variant.qcow2
Formatting 'variant.qcow2', fmt=qcow2 size=10737418240 backing_file='base.qcow2' encryption=off cluster_size=65536
$ du -skh variant.qcow2 
136K	variant.qcow2

Новый образ унаследован от базового, теперь при работе с ним чтение происходит либо из базового, либо с него, а запись только в него. Теперь мы можем загрузиться с этого нового образа и внести какие-то изменения, чтобы получить первый вариант конфигурации виртуальной системы. Аналогично можно создать любое число подобных образов, имеющих в качестве основы один базовый.

А можно пойти ещё дальше, нарастив глубину наследования, в зависимости от потребности в конкретных конфигурациях, главное не забывать всякий раз «замораживать» образ, который будет использоваться в качестве базы, чтобы предотвратить любую возможность его изменения, в противном случае наследующие образы могут оказаться некорректными.

Рекомендую вам по окончании настройки замораживать вообще все образы, чтобы всегда иметь чистые конфигурации, но чтобы загрузить виртуальную машину с такими образами нам потребуется режим снимка:

kvm -m 512M -hda variant.qcow2 -hdc temp.qcow2 -shapshot

При запуске машины таким образом все операции записи будут производиться во временный снимок, который, кстати, при желании можно и сохранить, воспользовавшись консолью Qemu.

Вместо заключения

В статье я попытался описать все аспекты своей работы с Qemu, который считаю действительно мощным и простым в использовании комбайном виртуализации широкой области применения.

Если что-то забыл или пропустил, потом добавлю.