LINUX.ORG.RU
Форум — General  

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

 


0

2

Не понимаю одну вещь, может кто-нибудь объяснит. Вот для системы виртуализации QEMU-KVM есть два формата виртуальных жёстких дисков: raw и qcow2. Ну ещё есть просто qcow, vmdk, vdi,.. ладно. Поискал в гугле о разнице форматов, многие пишут, что диски qcow2 при всех их преимуществах тормозят сильно, и, кстати, ещё советуют LVM, как с которым управляться мне не очень понятно.
Вобщем мог бы кто-нибудь в простой форме объяснить как устроены виртуальные диски. Ну с форматом raw (он же img) всё понятно, это просто последовательность байтов. Операционная система, работающая в ВМ, о ВМ ничего не должна подозревать, на жёстком диске создаются разделы, разделы форматируются и т. д..
Как устроен формат qcow2 не понятно. Он, например, позволяет автоматически увеличивать размер виртуального диска. Как это происходит? Ведь данные находятся не на диске, а на его разделах. А если раздел зашифрован и хостовая система не может знать сколько там свободного пространства? И опять операционная система, работающая в ВМ, о ВМ ничего не должна подозревать. А если разделов несколько? Получается, что будет увеличен диск, внутри него будет увеличен раздел, а другие разделы будут подвинуты? Но это же не так просто. Когда я под виндой ещё пользовался различными программами для двиганья разделов, я помню что это возможно только если раздел не имеет ошибок. И начало и конец раздела должны быть обязательно подогнаны к началу и концу цилиндра.
А вообще я задумал качестве диска для ВМ использовать раздел физического диска, чтобы установленную операционную систему можно было запускать как в гипервизоре, так и в дуалбуте. Такое вообще возможно? Гостевой ОС должна быть Windows Server. Нужно как-то сделать, чтобы некий раздел физического диска был бы одновременно и разделом виртуального диска. Вроде пишут, что с помощью LVM такое возможно. Я сколько не читал на эту тему, суть LVM всё равно отказываюсь понимать, группы томов там какие-то.
Мог бы кто-нибудь, кто смог разгрызть эту тему, сюда написать.

★★★★★

Ответ на: комментарий от King_Carlo

Вот этот материал я как раз и не понял. Первый вопрос: где LVM применим практически и чем это отличается от software RAID?

sunny1983 ★★★★★
() автор топика
Ответ на: комментарий от sunny1983

LVM применим только в Линуксах (пишут что в Бздях тоже поддерживается, но я хз насколько полностью). Для вашей задачи вам нужно брать отдельный хард и отдавать его весь виндовому гостю.

Главное в LVM - абстракция от реальных разделов/дисков и их размеров. LVM может быть похож на RAID-0, если он будет «размазывать» данные на несколько PV в переделах VG, но на мой взгляд это плохая идея (и по умолчанию LVM это не делает). Так что в этом плане LVM это не замена RAID ни в каком виде.

trancefer ★★
()
Ответ на: комментарий от i-rinat

http://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/qcow2.txt

Еще можно оправить читать Большую Советскую Энциклопедию.

Как я понимаю, у qcow две особенности:
1) Образы qcow содержат только блоки с данными. А образы других форматов - там задаешь размер и образ содержит как блоки с данными, так и пустые блоки.
2) qcow позволяет «дописывать» на read-only образы. Возможно я не прав, но я себе это представляю по аналогии с docker контейнерами, только на уровне блочного устройства: есть образ ОС; есть образ софта. Ты указываешь «структуру»: сначала ОС, потом софт. Для получения итогового образа оно накладывает образ софта на образ ОС. То есть файлы (точнее, блоки), которые есть и там и там, берутся из образа софта, остальные просто merge'аться.

Kroz ★★★★★
()

Он, например, позволяет автоматически увеличивать размер виртуального диска. Как это происходит? Ведь данные находятся не на диске, а на его разделах. А если раздел зашифрован и хостовая система не может знать сколько там свободного пространства? И опять операционная система, работающая в ВМ, о ВМ ничего не должна подозревать. А если разделов несколько? Получается, что будет увеличен диск, внутри него будет увеличен раздел, а другие разделы будут подвинуты?

Это всё довольно просто сделать. Запросы гостевой системы на запись или чтение с диска транслируются в запросы на запись/чтение из файла, так ведь? При этом если гостевая система хочет считать байт номер 100500, то виртуальная машина может считать из файла байт номер 284597 и сказать, что это есть байт номер 100500.

Поэтому виртуальная машина может поступить так же, как, скажем, memory management unit управляет страницами памяти: представить себе диск разбитым на блоки, скажем, по 4096 байт. Сделать в файле с виртуальным диском каталог этих блоков. Сделать входы в каталоге для всех блоков, но физически хранить не все блоки, а только те, которые не заполнены нулями (вначале считать все блоки заполненными нулями). Когда гостевая система записывает что-нибудь в определённый блок, если этот блок ещё не находится физически в файле, дописать его в конец файла и указать в оглавлении, где он в файле находится. При этом если система записывает в байт 100500, то есть в блок 24 (округ_вниз(100500/4096) = 24), то блоку 24 ему необязательно быть физически именно 25-м блоком в файле (начиная с 0): просто в оглавлении это будет 25-й вход и там будет указано, где он в файле.

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

Но чтение/запись на жёсткий диск производится не отдельными байтами, а либо логическими блоками (LBA), либо по адресации цилиндр-головка-сектор. Их виртуальная машина должна сэмулировать, что не сложно: нужно просто решить, сколько логических блоков умещается в один реально используемый блок. А пересчёт из ЦГС в LBA делается по стандартной формуле.

На практике всё немного сложнее, так как есть ещё снапшоты, copy-on-write и всякие метаданные, но суть, как я понимаю, такова.

proud_anon ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General