В QEMU есть несколько способов подключить блочное устройство для виртуальной машины. Изначально это было реализованно следующим способом:

 -hda /dev/sda1

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

• При подключении виртуальных дисков возможно использовать только тот интерфейс, который на виртуальной манише рассматривается как /dev/hda (hda,hdb,hdc,..); Для CD предусмотрен параметр -cdrom
• При подключении файла (или устройства) к виртуальной машине QEMU использует только параметры по умолчанию.

drive

Чтобы устанавливать другие параметры (тип шины, использование кеша и т.д.), В QEMU был добавлен параметр -drive. Хотя изначально он использовался для установки параметров как для backend и так и frontend, в настоящее время он используется только для установки параметров backend, то есть параметров, влияющих на подключение виртуального устройства внутри виртуальной машины

-drive file=/dev/sda1,if=ide,cache=writeback,aio=threads

device

Настройка всех параметров блочного устройства одной опцией с течением времени оказалась неразумной. Поэтому опции были разделены на две. Параметры backend, т. е. те, которые используются для настройки среды виртуализации. И frontend, которые влияют на то, как устройство подключенно в виртуальной машине. Для этого набора параметров была введена новая опция -device, который содержит идентификатор id диска, заданный параметром -drive.

Следующий пример конфигурации подключит диск с идентификатором ide0-hd0, и полученный результат совпадает с простым подключением виртуального диска, как показано во введении.

-drive file=/dev/sda1,id=ide0-hd0,if=none,cache=writeback,aio=threads -device ide-drive,bus=ide.0,drive=ide0-hd0

Локальные блочные устройства в виртуальной машине

Использование физических блочных устройств для виртуальных машин на сегодня распростанено не сильно в виду повсеместного использования виртуальных дисков. Технически мы имеем возможность запустить виртуальную машину с какой-нибудь проприетарной системой со старого жесткого диска. Однако в этом случае лучше сначала сделать образ диска (image) с помощью dd и запустить систему уже с него.

Как и локальное блочного устройство к виртуальной машине может быть подключено..

• Локальный RAID массив — устройство типа md
• Master DRBD (сетевой RAID1) — устройство типа drbd
• Дисковый раздел, созданный в группе LVM — устройство типа dm
• Обычный файл подключенный через loop — устройство типа loop

• Блочное устройство с другого компьютера экспортированное с помощью NBD сервера — устройство типа nbd

  
  

  (Здесь так же стоит упомянуть про Ceph устройство типа rbd и ZFS устройство типа zvol — прим.пер)
  
  

  
  

  NBD

  
  

  Рассмотрим концепцию подключения блочного устройства с удаленного компьютера по сети. См отдельное руководство для NBD.

  
  

QEMU имеет интегрированное NBD API, так что удаленное блочное устройство, расшаренное с помощью NBD-сервера, может быть напрямую подключенно к виртуальной машине через QEMU — см. рисунок слева.

Однако NBD это достаточно простой протокол, который не использует аутентификацию на удаленном сервере и не контролирует состояние соединения. Протокол NBD предполагает, что клиент может повторно подключиться, в случае если соединение с сервером прервалось, но к сожалению QEMU так не делает.

Частично ситуация может быть решена путем подключения нескольких NBD устройств и создания внутри них виртуального RAID-массива. У этого подхода есть несколько преимуществ и один фатальный недостаток. Если какое-то из устройств отключится, то ничего страшного не произойдет. Но если они вылятят все одновременно = будет плохо. Операции ввода-вывода в виртуальной среде будут намного быстрее, поскольку запросы будут выполняться параллельно сразу к нескольким физическим машинам (NBD-серверам). Но с другой стороны это потребует больше ресурсов виртуального процессора и виртуальной памяти.

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

Обращаться к NBD серверу лучше используя NBD устройство виртуальной машины. Особенно хорошо, с точки зрения I/O-производительности, построение RAID массива из NBD-устройств.

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

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

Основная проблема RAID-массивов поверх NBD устойств заключается в том, что вам нужно быть очень осторожным при подключении с NBD-сервера устроства, которое входит в RAID-массив. Это достаточно деликатный процесс с высокой вероятностью фатальной ошибки, которая может привести к потере данных. Достаточно небольшой опечатки. См. описание аварии со смертельным исходом машины от 21 июля 2012 года на странице Peanuts

Недостатком является то, что блочное устройство с которым уже работает одна виртуальная машина, нельзя подключать в другом месте, если этого не позволяет его файловая система — это аналогично iSCSI (internet Small Computer System Interface — сетевая версия SCSI) или AoE (технология ATA over Ethernet).

Виртуальные диски

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

Форматы виртуальных дисков

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

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

root@stroj~# qemu-img info /path_to_file/soubor.img

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

root@stroj~# qemu-img info gluster+tcp://192.168.0.2/volume_name/soubor.img

Виртуальный диск VDI можно идентифицировать только через API Sheepdog:

root@stroj~# qemu-img info sheepdog:192.168.0.2:8000:vdi_name

Для виртуального диска экспортированного с NBD сервера, необходимо проследить за тем, что указаны правильный сервер и правильный порт, потому что NBD не использует какой-либо другой механизм идентификации или аутентификации, который исключал бы путаницу с другими виртуальными дисками (новая версия nbd-server использует только один порт и идентифицирует устроства по имени — прим.пер):

root@stroj~# qemu-img info nbd:192.168.0.2:8000

192.168.0.2
IP-адрес узла, с которого подключается виртуальное устройство. Если это тот же хост на которо запускается qemu-img info, вместо IP-адреса можно использовать localhost

8000
Номер порта, на котором слушает демон или сервер. По умолчанию Sheepdog использует порт 7000, но он также может быть запущен на другом порту, что бы избежать конфликтов с другим приложением. NBD-сервер может слушать разные порты, в случае если экспортировано более одного устройства.

raw
в целом представляет собой просто набор данных, записанных в том же формате, как и на обычном блочном устройстве. Файл размера 5G будет занимать это место целиком, независимо от того, содержит он полезные данные или просто пустое пространство. (что не применимо к разреженным файлам — прим.пер)

qcow
Отличается от формата raw тем, что может быть инкрементным, потому он растет постепенно — это удобно для тех файловых систем, которые не поддерживают разреженные файлы, например FAT32. Этот формат также позволяет создавать отдельные инкрементные копии из одного базового диска. Использование такого «шаблона» экономит время и место на диске. Кроме того, он поддерживает AES шифрование и сжатие zlib. Недостатком является то, что, в отличии от raw-дисков, такой файл нельзя смонтировать на машину непосредственно на которой он находится. К счастью есть утилита qemu-nbd, которая может экспортировать этот файл как сетевое блочное устройство и затем подключить его к NBD устройсту.

qcow2
представляет собой обновленную версию формата qcow. Основное отличие заключается в том, что он поддерживает снапшоты. В остальном они принципиально не отличаются. Возможно также встретить qcow2, который внутри определяется как QCOW врсии 3, некогда давно он был включен в формат qcow2. Фактически, это модифицированный qcow2 с параметром lazy_refcounts, который используется для снапшотов. Так как разница всего лишь в одном бите, qemu-img с версии 1.7 имеет опцию "amend", чтобы изменить его. Более ранние версии qemu-img такой возможности не имеют. Если вы хотели изменить версию формата, необходимо было преобразовать виртуальный диск в новый файл, во время преобразования параметром compat устанавливалась версия, для которую нужно было уменьшить вместо "1.1" "0.10". Наличие опции "amend" удобно тем, что нет необходимости перезаписывать данные из-за таких незначительных изменений.

qemu-img create -f qcow2 -o compat=1.1 test.qcow2 8G

http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html

qed
Это инкрементный формат COW виртуального диска, который создает наименьшую нагрузку на хост. Он не поддерживает никакого сжатия и использует две параллельные таблицы для адресации блоков данных (кластеров). К сожалению, ни один разработчик в течение долгого времени не был заинтересован в его развитии, поэтому его использование несет некоторые проблемы, которые будут упомянуты.

vdi
формат виртуального диска, используемый системой виртуализации Oracle Virtualbox.

vmdk
формат виртуальных дисков, используемый продуктами VMware. Это тоже формат который позволяет файлу постепенно расти. Однако он имеет большое преимущество по сравнению с qcow2 и qed форматами, которые тоже могут использоваться с бездисковыми решениями или с сетевыми файловыми системами. Он позволяет вам иметь файл виртуального диска, разделенный на несколько мелких файлы с размерам по 2 ГБ. Это осталось еще с тех времен, когда файловые системы не могли создавать файлы размером более чем 2 ГБ. Преимущество состоит в том, что если такой виртуальный диск реплицируется по сети, то передаются меньшие объемы данных, а синхронизация выполняется намного быстрее (например в случае GlusterFS). В случае бездискового решения он также используется для хранения только небольших файлов с различиями для каждого снапшота

vhdx
формат виртуального диска, используемый системой виртуализации Microsoft Hyper-V

vpc
формат виртуального диска используемый системой виртуализации Microsoft VirtualPC.

1. ^ Возможно использование только на преаллоцированных образах (fixed)
   

Используемые API

Помимо файловых форматов qemu-img так же работает с «форматами», которые предоставляются с помощью API, через который эти блочные устройства могут быть доступны удаленно.

nfs
файл виртуального диска подключенный к QEMU через протокол NFS

iscsi
связь с блочным устройством осуществляется через протокол iSCSI. Одно устройство не может быть одновременно использованно на более чем одном клиенте.

nbd
Получить доступ через протокол NBD можно очень быстро. Это потому что протокол очень простой. Это преимущество, но в то же время недостаток. Это может быть удобно, когда несколько клиентов могут подключиться к одному NBD серверу, если они используют локальное соединение через xnbd-сервер. Однако, поскольку nbd не имеет механизмов зашиты или аутентификации, легко может возникнуть ситуация, когда клиент случайно подключится к неправильному устройству, которое в данный момент времени может уже использоваться и повредит его.

ssh
соединение с удаленным сервером выполняется через sshfs

gluster
используется API файловой системы GlusterFS для доступа к файлу виртуального диска. Если файл является частью реплицированного или распределенного тома, он будет распределять сохраненяемые данные между другими узлами. Это позволяет ему, в случае сбоя, быть доступным и на других нодах.

sheepdog
также является распределенной файловой системой с поддержкой репликации. В отличие от GlusterFS, виртуальный диск через API доступен не как файл, а как блочное устройство. Это выгодно с точки зрения производительности, но невыгодно, если нам нужно выйти за пределы среды Sheepdog.

paralles

Виртуальные диски на сетевом хранилище

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

В этом случае также обеспечивается высокая доступность и достаточный объем для удаленного хранения.

Использование NFS

Sheepdog

GlusterFS

Виртуальные машины без блочных устройств

Без блочных устройств могут работать операционные системы, которые умеют загружаться по NFS или с проброшенной с помощью Plan9 хостовой файловой системы.