Расширение файла виртуальной машины kvm

Обновлено: 30.06.2024

Зачем это нужно, если уже есть ряд фронтендов разного уровня (libvirt, Proxmox, RHEV итд)? В любом случае фронтенды вынуждены вызывать qemu с множеством опций, поэтому в некоторых случаях (тестирование новых возможностей, отладка, развлечение) намного приятней и понятней работать непосредственно с qemu. Кроме того знания полезны для общего развития и понимания работы систем.

Как связаны qemu и технология KVM? Qemu - эмулятор, который может работать и без KVM, но использование аппаратной виртуализации значительно ускоряет работу гостевых систем, поэтому KVM является предпочтительным вариантом.

Создание файла образа

Для начала стоит проверить, поддерживается ли аппаратная виртуализация вашим процессором. Для этого стоит убедиться что в параметрах камня имеется флаг vmx или svm (В зависимости от производителя Intel/AMD.)


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

После установки следует перезагрузить компьютер, чтобы система подключила модули ядра kvm и kvm_intel (kvm_amd). После перезагрузки проверим, подключены ли модули ядра:

Если нет желания перегружаться, можно в самим подключить эти модули:

Далее, если все хорошо, то создаем файл для образа нашей системы.

create = создать файл

-f = укахывает на формат файла, лучше использовать формат qcow2 родной для QEMU, qcow2 формат записи образа виртуальных машины с поддержкой сжатия, снапшотов и шифрования. Кроме того qcow2 образ занимает столько места, сколько данных записано в него виртуальной машиной, вне зависимости от размера создаваемого при создании

RELS1.qcow2 = имя нашего файла образа

8G = размер файла для образа, в данном примере 8 Гигабайт.

Установка ISO образа в QEMU

Сначала нам надо запустить ISO образ в QEMU, затем проинсталлировать, и потом уже использовать полученную виртуальную систему.

Разберем по порядку, что тут и как:

-cpu SandyBrige = опция отвечающая за эмуляцию командных инструкций процессоров под кодовым названием SandyBrige. В принципе вы можете узнать какие еще процессора поддерживает qemu и выбрать свой.

Будет список процессоров:

-enable-kvm = включаем поддержку kvm ядра. Если мы не включим эту опцию, то qemu будет запущен без использования kvm.

-net nic,vlan=0 -net user,vlan=0 = включение эмуляции сетевого адаптера.

-hda RELS1.qcow2 = указываем какой файл образ будем использовать. Выше было описано, как его создавать.

-cdrom ./ROSA-Server-6.4-x86_64-DVD.iso = опция указывает, что мы будем использовать ISO образ который находится виртуально на устройстве cdrom.

-boot d = указывает, что грузиться qemu будет с cdrom (т.е. с нашего ISO образа) но буква d говорит о том, что ISO образ находится не в приводе cdrom, а на жестком диске.

-m 2048 = указывает, сколько памяти будет выделено под работу qemu. В данном примере 2 Гигабайта.

Итак, мы разобрали наши ошпции, и можно запускать на инсталляцию. Однако есть некоторые ньюансы. Например некоторые образы дистрибутивов не работают из-за настроек vga карты. По- этому, если такое случается, не расстраивайтесь, добавьте в команду запуска опцию: -vga std.

Так же, некоторым захочется иметь еще и звуковую карту рабочую. Тогда в строку запуска следует добавить опцию: -soundhw ac97.

Ну и для гурманов, конечно же можно поиграться с указанием количества процессоров и потоков. Например, можно указать: -smp 4,core=4.

Запуск виртуальной ОС в QEMU

После того, как установили систему. Можно пробовать ее запускать.

Отличие данной строки запуска, от строки запуска с ISO образом в том, что в первом случае мы указываем параметр: -cdrom ./ROSA-Server-6.4-x86_64-DVD.iso и -boot d. Здесь, же нам это не требуется, т.к. уже имеется файл с установленной виртуальной системой.

date

20.02.2021

directory

KVM, Linux

comments

комментариев 7

В этой статье мы поговорим об изменении размера дисков виртуальной машины KVM, рассмотрим используемые форматы виртуальных дисков. Покажем, как правильно увеличить диск виртуальной машины в гипервизоре KVM на Linux без потери данных, а также обсудим варианты уменьшения размеров дисков.

Увеличение диска виртуальной машины KVM

Расширение виртуального диска со стороны KVM

Для того, чтобы проводить работы с диском, виртуальная машина должна быть отключена, иначе мы не сможем что-либо сделать. Рассмотрим пример с увеличением диска размер которого изначально был 20Гб.

Чтобы посмотреть параметры диска виртуальной машины KVM, воспользуйтесь командой:

qemu-img info /путь_до_диска

Вывод команды будет примерно такой:

qemu-img информация о диске виртуальной машины

Мы видим, что у нас есть два поля которые указывают на размер, это virtual_size и disk_size:

  • virtual_size – размер виртуального диска, указанный при создании или расширении диска (в этом примере максимальный размер диска – 20 Гб);
  • disk_size — размер файла диска в текущий момент, т.е. сколько сейчас занимает образ диска места на физическом сервере (относится только к формату qcow). В нашем пример виртуальный диск занимает всего 1,6 Гб на хранилище.

И сразу о форматах. Я рекомендую при создании виртуальных машин на KVM использовать формат диска qcow2, а не raw. Чуть позже я объясню почему.

Если сразу проверить вывод информации об образе диска, мы увидим, что он расширился:

Часть работы мы сделали, но требуется и проведение работ со стороны виртуальной машины в гостевой ОС. Далее мы покажем, как увеличить размер диска в гостевых CentOS 7 и Windows Server 2012.

Если вы планируете добавить дополнительный виртуальный диск для ВМ на KVM гипервизоре, используются qemu-img и virsh.

Расширение раздела в виртуальной машине с Linux CentOS

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

После подключения к серверу, проверяем наличие нашего дополнительно подключенного места:

добавление места в гостевой linux

На скриншоте видно, раздел /dev/vda2 имеет размер 20Gb, а доступное место на диске у нас больше.

Подправим этот момент и расширим раздел /dev/vda2 до максимального объема:

После чего нам нужно сделать рестарт виртуальной машины и выполнить команду для применения расширения диска:

В итоге мы получили расширенный раздел /dev/vda2. Теперь по порядку, что именно мы сделали:

После перезагрузки проверим диск командой:

В некоторых источниках для выполнения данной процедуры указывают команду:

Но с файловой системой xfs это не работает!

Работы по расширению диска на виртуальной машине с ОС CentOS 7 закончены.

Увеличение диска в гостевой Windows Server

Подключаемся к виртуальной машине через rdp или VNC и выполняем работы по расширению диска.

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

Как уменьшить размер виртуального диска в KVM?

В своей работе, ранее я довольно часто сталкивался с данным вопросом, но к сожалению, безболезненно уменьшить диск на виртуальной машине в KVM нельзя! Единственный приемлемый размер уменьшения размер диска виртуальной машины KVM на физическом хранилище – его сжатие через конвертацию.

В интернете фигурирует много статей, якобы благодаря которым вы можете уменьшить размер диска на виртуальной машине, но это не работает.

Я приведу несколько примеров, на которые я натыкался и которые лично мною были проверены.

Уменьшение KVM диска с помощью утилиты qemu

На ряде ресурсов описаны действия, выполняемые с помощью утилиты qemu. В них предлагается уменьшить размер диска виртуальной машины с помощью команды:

qemu-img resize /путь_до_диска -5G — уменьшаем диск на 5G

Или такой вариант с указанием конкретного размера:

qemu-img resize /путь_до_диска 25G — указываем размер диска в 25G

Что происходит после выполнения данной команды? Запускаем сервер и конечно система не грузится:

qemu-img resize уменьшение диска в kvm ломает файловую систему

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

Уменьшение виртуального диска с подменой образа

Уже не такой распространенный в инструкциях вариант — это уменьшение диска, с подменой на старый. То есть, вы создаете новую виртуальную машину с нужным вам размером диска. После чего, подменяете старый образ диска в новый образ и судя по описанию статей в разных источниках, это работает. Я так же сделал проверку и это сломало файловую систему, как и в первом варианте. Я приведу пример команды:

virt-resize /старый_образ_диска /новый_образ_диска

Приводились так же варианты, с конвертацией диска с формата raw в формат qcow2, НО я изначально создаю машины в данном формате и объясню почему.

Форматы дисков KVM и сжатие диска в qcow2 формате

В самом начале статьи, я упомянул про эти два формата.

raw – в переводе «сырой». Преимущество формата, максимальная производительность, универсальность формата. Минусов масса, основные это:

  • Диск занимает все дисковое пространство на физическом сервере, которое ему выделили;
  • Нельзя создать снапшоты.

Qcow2 – это родной формат гипервизора QEMU, а так же QEMU-KVM. Это максимально удобный формат виртуального диска из всех поддерживаемых в KVM. Образ диска увеличивается по мере накопления данных на виртуальной машине, поддерживаются снапшоты.

Чем хорош формат qcow2? Вам в принципе не нужно уменьшать размер виртуального диска, так как диск занимает на сервере, ровно столько, сколько места там занято. Если же у вас данные на сервере постоянно перезаписываются и бывает такое, что диск «распух», его можно с легкостью сжать. Рассмотрим такой вариант. Я забью нулями некоторое дисковое пространство и после чего удалю файл:

dd if=/dev/zero of=/mytempfile
rm -rf /mytempfile

уменьшение размера диска в kvm через qemu-img convert

При проверке с сервера, образ диска сначала весил 2.4G после чего расширился до 5.9G:

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

Бэкапим файл диска, останавливаем виртуальную машину и после чего выполняем следующие действия:

qemu-img convert -O qcow2 /старый_образ /новый_образ

После чего можно проверить размеры двух дисков:

Как видим, размер сжатого диска 1.6G. Переименуем новый образ диска в нужный нам и запустим виртуальную машину:

Контрольная проверка с сервера:

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

Это все, что я хотел в данной статье рассказать. Если у кого-то из посетителей сайта есть рабочий способ по уменьшению диска на KVM, именно уменьшения (не сжатие) и именно рабочий, предлагайте свои варианты и я обязательно их протестирую.

Предыдущая статья Следующая статья Virt-Manager: графическая консоль управления KVM Резервное копирование виртуальных машин в KVM Управление числом vCPU и ядер в виртуальной машине Управление виртуальными машинами KVM из консоли

На самом деле в своей работе и ext4 пробовали уменьшать, получилось то, что получилось выше)
Ни разу нормально ничего не уменьшилось. Посыл раздела по уменьшению был такой: куча статей с вариантами уменьшения диска, которые гробят систему. А некоторые в принципе не срабатывают даже, непонятно тестируют ли вообще люди то, о чем пишут. Да и с образом в формате qcow2 смысла уменьшать разделы не вижу, лишние нервы. Есть vds не занимает место, то пусть и будет там раздел хоть на 100Гб) На днях еще раз проверю с ext4 и отпишусь, но последний раз это окончилось плачевно.

Виртуалка с диском на 1000гб будет делать бэкапы гораздо дольше чем со 100гб

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

Добавлю свои 5 коп.: Если после увеличения размера образа свободное место не отражается в VM c Windows Server, а перезагрузка VM затруднительна, то можно решить проблему командой DISKPART RESCAN

tux and beastie

Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.

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

$ egrep '(vmx|svm)' /proc/cpuinfo

Если есть — это замечательно.

Подготовка операционной системы

Установку Debian Squeeze я, пожалуй, описывать не буду: если уж вы добрались до KVM, то установка системы — плёвое дело.

Устанавливать нужно будет 64-битную OS, поскольку необходимые пакеты есть только для этой архитектуры.

В Debian Squeeze «свежесть» пакетов с KVM и сопутствующих программами нас совсем не устраивает, поскольку очень много всяких фиксов и фич попросту пройдут мимо нас. Поэтому мы добавим репозитории Debian Sid и experimental:

Указываем, что у нас базовый дистрибутив stable, а не то, что подумала система:

Оттуда нам понадобятся пакеты:

Из стабильного репозитория нам будут нужны:

На вашем рабочем десктопе вы можете поставить virt-manager (GUI-утилита), который позволит удобно создавать нужные конфигурации виртуальных машин.

Ядро чем «свежее» — тем лучше (в известных пределах конечно: из git, например, я бы ставить не рекомендовал). Хорошим вариантом будет 2.6.39, вышедшее недавно.

Следует отметить, что в стандартном ядре отсутствует модуль для поддержки записи в UFS2, и если планируется запускать гостевую FreeBSD, потребуется собрать ядро с этим модулем. Ну и, конечно, в Debian-овском ядре отсутствуют свежие версии cgroups.

Что должно быть включено в ядре для использования максимального объема требуемого функционала:

CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NET_CLS_CGROUP=y

Затем идём по ссылке и устанавливаем все deb-пакеты оттуда, копируем insmod.static в /sbin/insmod.static (это нужно, поскольку в работе libguestfs использует статически скомпилированную версию insmod, а в Debian и Ubuntu такого файла просто нет, однако в последней версиии febootstrap эту проблему устранили, insmod.static более не нужно загружать на сервер). libguestfs позволяет нам получать доступ к диску VDS через API libguestfs(C, Perl, Python, PHP) или через утилиту guestfish.

Первый блин

Сейчас мы установили все, необходимое для запуска VDS, их доступа в сеть и установки самой виртуальной машины.

Давайте попробуем что-нибудь поставить, например, тот же самый Debian. Пока без настройки сети, просто, по умолчанию.

Скачиваем установщик netinstall:

Редактируем /etc/libvirt/qemu.conf, чтобы виртуальные машины работали у нас от непривилегированного пользователя:

user = "username"
group = "libvirt"

Поскольку у нас будут использоваться tun-устройства, нужно выставить capability CAP_NET_ADMIN, сделать это можно как для отдельного исполняемого файла, так и для пользователя в целом, или настроить чтобы libvirt не сбрасывал нужные права для qemu/kvm.

Выставляем для отдельного файла:

sudo setcap cap_net_admin=ei /usr/bin/kvm

Или выставляем для пользователя в целом в файле /etc/security/capability.conf:

Или выставляем соответствующую настройку в /etc/libvirt/qemu.conf:

Добавим пользователя в группу libvirt и kvm:

Запустим установку виртуальной машины:

$ virt-install --connect qemu:///system -n debian_guest -r 512 --arch=i686 --vcpus=1 --os-type=linux --os-variant=debiansqueeze --disk debian-6.0.1a-i386-netinst.iso,device=cdrom --disk debian_guest.img,bus=virtio,size=2,sparse=false,format=raw --network=default,model=virtio --hvm --accelerate --vnc

Подробно разберём параметры, которые мы указали:

  • --connect qemu:///system URL, по которому мы подключаемся к KVM. Подключаться можно через ssh.
  • -n debian_guest Имя гостевой системы.
  • -r 512 Выделяемый объём оперативной памяти в мегабайтах.
  • --arch=i686 Архитектура гостевой операционной системы.
  • --vcpus=1 Количество виртуальных процессоров, доступных гостю.
  • --os-type=linux --os-variant=debianlenny Специфичные для данной операционной системы параметры.
  • --disk debian-6.0.1a-i386-netinst.iso,device=cdrom Загружаемся с диска, образ которого указали.
  • --disk debian_guest.img,bus=virtio,size=2,sparse=false,format=raw Создаём образ системы размером 2Гб, который сразу помещаем на диск (можно создать образ нулевого размера, но тогда возможна фрагментация, что получается несколько медленнее). Формат простой, можно сделать с dd файл. Драйвер диска virtio, использовать лучше virtio, чем ide: производительность их отличается если не на порядок, то в разы.
  • --network=default,model=virtio Сетевые настройки по умолчанию. В этом случае libvirt создаст мост, сделает dhcp сервер и выдаст через него адрес для доступа виртуальной машины.
  • --hvm Полная виртуализация — то есть, можно использовать собственные ядра.
  • --accelerate Работа через /dev/kvm.
  • --vnc Запускаем VNC, чтобы подключаться к текстовой консоли.
Утилиты настройки и управления

Для управления установкой и для клонирования виртуальных машин у нас есть две замечательные утилиты — графическая и консольная: virt-manager и virsh, соответственно. Конечно, консольная версия намного богаче по возможностям, но ничто не сравнится с видом графиков, от которых сердце сисадмина млеет.

Думаю с virt-manager вы и сами разберётесь, давайте попробуем покопаться в консольных внутренностях virsh. Вот несколько команд которые стоит выполнить и посмотреть что из этого получится:

$ virsh --connect qemu:///system list --all
$ virsh --connect qemu:///system dominfo debian_guest
$ virsh --connect qemu:///system stop debian_guest

Чтобы тысячу раз не писать --connect qemu:///system, добавьте:

export VIRSH_DEFAULT_CONNECT_URI= qemu:///system

В .bashrc или просто выполните эту команду в терминале.

Подготовка сети

В официальной документации предлагается использовать несколько вариантов организации сети: NAT, bridged и прямое использование сетевых карт. И, к сожалению, в различных примерах, которые я нашел в сети и на официальном сайте, рассматриваются только NAT и bridged сети.

В моей конфигурации используются TUN/TAP устройства, на которые с eth0 маршрутизируется трафик. Коротко опишу, почему выбран именно такой способ маршрутизации:

NAT нам не подходит, поскольку каждая VDS должна быть доступна из сети напрямую.
Схема с мостами не очень надёжная, поскольку теоретически есть возможность «захвата» IP адреса чужой виртуальной машины.
Итак:

<interface type='ethernet'>
<mac address='52:54:00:ef:40:1d'/>
<ip address='10.10.10.100'/>
<target dev='debian_guest'/>
<model type='virtio'/>
</interface>

Данный участок конфигурации нужно указывать непосредственно в конфигурационном файле гостя, расположенного по адресу /etc/libvirt/qemu/debian_guest.xml. Редактировать лучше всего через:

$ virsh edit debian_guest

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

Создадим необходимое нам виртуальное устройство.

Для начала нам нужно дать нашему пользователю возможность беспарольного обращения к системным командам. Для этого добавим в sudoers:

Cmnd_Alias QEMU = /sbin/ifconfig, /sbin/modprobe, /usr/sbin/brctl, /usr/sbin/tunctl, /sbin/sysctl, /bin/ip, /usr/bin/cgcreate, /usr/bin/cgdelete, /sbin/tc
username ALL=(ALL:ALL) NOPASSWD: QEMU

Включим возможность форвардинга и проксирования arp-запросов:

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv4.conf.all.proxy_arp=1

Также можно добавить эти параметры в /etc/sysctl.conf и применить их:

Создадим виртуальную сетевую карту и поднимем устройство:

sudo tunctl -b -u username -t debian_guest
sudo ifconfig debian_guest 0.0.0.0 up

Создадим маршрут на нужное нам устройство с нужного IP-адреса:

sudo ip route add 10.10.10.100 dev debian_guest

Теперь можно запустить VDS:

$ virsh start debian_guest

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR=="xx:xx:xx:xx:xx:xx", ATTR=="0x0", ATTR=="1", KERNEL=="eth*", NAME="eth1"

Нужно удалить этот файл и перезагрузить VDS — после этого сетевая карта определится корректно.

Пропишем новые сетевые настройки в гостевой системе:

10.10.10.10 — это IP-адрес хост-системы. Теперь мы сможем попинговать другие машины.

Добавим DNS-серверы в /etc/resolv.conf, и будет совсем замечательно:

К слову, замечу, что оказалось очень удобно называть сетевые устройства, принадлежащие VDS, также, как и сами VDS — отпадает необходимость искать, кому принадлежит устройство tap0 или vnet0, или как там ещё можно их обозвать.

Если понадобится выдать виртуальной машине ещё один IP-адрес, достаточно будет просто на хост-машине прописать ещё один маршрут:

А в гостевой системе создать алиас для сетевого устройства:

В следующей части

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

Для начала стоит проверить, поддерживается ли аппаратная виртуализация вашим процессором. Для этого стоит убедиться что в параметрах камня имеется флаг vmx или svm (В зависимости от производителя Intel/AMD.)

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

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

Теперь можно использовать все прелести аппаратной виртуализации при помощи qemu. Например, для запуска liveCD на виртуальной машине вполне достаточно выполнить

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

Создание образа диска

Новый образ диска создается при помощи опции create:

Поддерживается несколько форматов образов виртуальных машин:

  • raw Файл содержащий точную копию диска, подключаемую к виртуальной машине.
  • qcow2 Формат записи образа вирт машины с поддержкой сжатия, снапшотов и шифрования. Кроме того qcow2 образ занимает столько места, сколько данных записано в него виртуальной машиной, вне зависимости от размера создаваемого при создании.
  • vdi Образ BM поддерживаемый VirtualBox.
  • vmdk Образ виртульных машин VMware.
  • И еще несколько (подробности в мане)

Для конвертации одного формата образа в другой используется опция convert:

Для того, чтобы просмотреть информацию об образе используется опция info

Шаблоны и снимки состояния

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

Пусть уже создан образ arch.qcow2 с установленной операционной системой на нём. Для того, чтобы на его основе создать еще несколько образов необходимо воспользоваться командами

Теперь существуют три образа: arch.qcow2, archnew1.qcow2, archnew2.qcow2. При этом два последних не занимают на диске существенного места и ссылаются на первый. При запуске виртуальной машины из образа archnew1.qcow2 в этот файл будут записываться только изменения относительно базового образа.

Ниже приведен вывод команды qemu info для базового образа и diff файла:

Видно, что в файле archnew1.qcow2 прописан файл базового образа. Соответвенно при переименовании или отсутствии файла базового образа все системы, основанные на нем не смогут запуститься. Поэтому в некоторых случаях полезно создать однин файл, который объединяет в себе как информацию заложенную в базовом образе, так и отличия записанные в отдельном файле. Это можно сделать так

После этого файл archnew3.qcow2 будет содержать с себе информацию как из archnew2.qcow2 так и из базового образа на котором он основан (arch.qcow2).

Без опции -u команда сравнивает базовые файлы (новый, который указан в команде, и старый, на котором основан конечный файл) и переписывает те изменения, которые гарантируют работоспособность системы с новым базовым файлом.

С опцией -u команда только перезаписывает имя базового файла не проверяя сохранение целостности информации. Эта опция полезна при переименовании базового образа и обновлении всех ссылок на этот файл в образах основаных на нём.

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

Снимки состояния системы в qcow2 образах

Для создания снапшотов необязательно работать с diff образами, как описано выше, можно пользоваться встроенной в qcow2 возможностью. Работа со снапшотами реализуется при помощи опции snapshot

И небольшой разбор по опциям:

При таком запуске некоторые вещи подключаются по умолчанию. Например видеокарта cirrus и sdl вывод изображения. Также автоматически подключается сетевой интерфейс с NAT на хост систему (это делается средствами qemu и работает достаточно медленно). Конечно есть и другие варианты для вывода видео и настроек сети, но это уже тема для отдельного поста.

Для работы с образами дисков в QEMU-KVM используется команда:

qemu-img.

Формат команды qemu-img:

Доступные варианты “subcommand”:

create - создание нового образа диска check - проверка существующего образа диска на наличие ошибок convert - конвертация образа в другой формат Подробнее про доступные форматы ниже. info - информация об образе диска snapshot - управление снимками дисков (snapshots)

ВАЖНО: данная опция не работает с образами диска формата RAW

commit - записать изменения образа rebase - создание образа диска на основании параметров эталонного диска
Под эталонным мы понимаем любой существующий образ, который задается в качестве эталона.

Создание нового образа диска – qemu-img create

Пример создания нового диска для гостевой виртуальной машины внутри файловой системы хоста.

ft – формат образа диска.
В Ubuntu поддерживаются следующие форматы виртуальных дисков:
vmdk,
vdi,
raw,
host_cdrom,
host_floppy,
host_device file,
qcow2,
qcow,
parallels,
cow,
cloop
(есть еще другие, но я лично их не пробовал создавать).
В реальной жизни обычно необходимы для работы только несколько форматов:

fname – Имя и путь к файлу образа диска.

ize – размер создаваемого диска.
Формат num<единицица измерения>.
Поддерживаются следующие сокращения единиц измерения: K (Kilobyte), M (Megabyte), G (Gigabyte), T (Terabyte).

Конвертация образа диска

qemu-img convert

Конвертации одного формата в другой при использовании образов дисков делается командой qemu-img convert:

-c – компрессия (сжатие) диска.
ВАЖНО: Компрессию поддерживают только qcow и qcow2 форматы.

-f ft – формат исходного диска. Опция не обязательная, конвертер сам умеет считывать заголовок формата образа. Задается только, если при определении формата возникла ошибка.

-O out_ft – формат целевого диска (какой формат мы хотим получить в результате выполнения команды)

-o options – Различные опции, которые допустимы для конкретной конвертации.

Читайте также: