Конвертація VMDK у QCOW2 для Proxmox: команди qemu-img, поради з продуктивності та типові помилки

У вас є VMDK, експортований із VMware, і кластер Proxmox, якому байдуже до вашої ностальгії. Міграція здається «тільки конвертацією диска», поки не стає нею: ВМ завантажується чорним екраном, конвертація повзе зі швидкістю 20 MB/s або qemu-img починає видавати «invalid VMDK descriptor» у поезії.

Це польовий посібник, який я хотів бачити частіше перед тим, як запускати конвертації на єдиній копії робочого диска. Він навмисно прямий. Ви тут, щоб перемістити байти безпечно, швидко і з менше сюрпризів, ніж у понеділок вранці під час вікна змін.

Ментальна модель: що саме ви конвертуєте

«VMDK у QCOW2» звучить як перетворення одного файлу. Насправді ви переводите формат контейнера зберігання, його стратегію розподілу та часто історію снапшотів у щось, що QEMU може ефективно запускати.

VMDK може бути:

• Однофайловий monolithicSparse (поширений у експорті та деяких бекапах).
• Дводільний: маленький descriptor текстовий файл плюс великий flat extent файл (поширено на ESXi datastore).
• Розбитий на шматки по 2GB (старіший/портативний стиль).
• Ланцюги снапшотів (delta disks), де «диск» — це стек файлів, які мають сенс лише разом.

QCOW2 також не «просто файл». Він може зберігати снапшоти, стиснення, шифрування та містить метадані, які можуть стати податком на продуктивність, якщо ставитися до нього як до сирого блочного пристрою. На Proxmox у вас також є друге рішення: файлова пам’ять (dir, NFS, CIFS) проти блочної (LVM-thin, ZFS zvol, Ceph RBD). Правильною ціллю часто взагалі не є QCOW2 — це raw на zvol або LVM-thin. Але іноді QCOW2 саме те, що треба, особливо для файлового зберігання та портативності.

Ось моє думка правило: сконвертуйте один раз, перевірте двічі, потім імпортуйте. Якщо ви конвертуєте в випадкову директорію з невідомою семантикою файлової системи і без верифікації, ви не мігруєте — ви граєтеся у ризик.

Цікаві факти & історичний контекст (корисний тип)

1. VMDK з’явився раніше за сучасну ідею «cloud image». Він розвивався в епоху, коли настільна віртуалізація та datastore визначали дизайн більше, ніж API-орієнтована автоматизація.
2. VMDK «descriptor + flat» — це фіча, а не баг. Маленький файл-дескриптор — це фактично метадані й вказівники; втратите його — і ви все ще можете врятувати flat extent, якщо знаєте геометрію та деталі формату.
3. QCOW (v1) з’явився раніше за QCOW2. QCOW2 його замінив, додавши можливості зі снапшотами та refcounting; він уже роками використовується за замовчуванням з хороших причин.
4. qemu-img старший за багато виробничих runbook. Це гострий інструмент; він робитиме саме те, що ви попросите, включно з незворотними виборами.
5. «Тонке provision» означає різні речі на різних шарах. Тонкий VMDK може перетворитися на товстий QCOW2, якщо вибрати неправильні прапори або пройти через невідповідний шлях.
6. Снапшоти VMware — не бекапи. Ланцюги снапшотів можуть бути крихкими; конвертації, що ігнорують структуру ланцюга, часто дають диски, які завантажуються, але несуть приховані невідповідності.
7. Продуктивність QCOW2 з часом значно покращилась. Сучасний QEMU має кращі опції кешування та aio, але метадані QCOW2 все ще коштують IOPS, особливо при випадкових записах.
8. Proxmox історично схилявся до raw для блочного зберігання. На ZFS і LVM-thin сирі томи зазвичай кращі за продуктивністю і передбачуваністю; QCOW2 блищить на файлових бекендах.

Попередні перевірки: не конвертуйте те, чого не розумієте

Перед конвертацією треба знати, що у вас є, де це лежить і як виглядає «правильно». Більшість невдалих міграцій — не помилки конвертації. Це відсутній контекст.

Завдання 1: Визначте тип VMDK і супутні файли

cr0x@server:~$ ls -lah /mnt/incoming/vmware-export/
total 68G
drwxr-xr-x  2 root root 4.0K Dec 28 10:14 .
drwxr-xr-x 12 root root 4.0K Dec 28 10:10 ..
-rw-------  1 root root  512 Dec 28 10:12 disk.vmdk
-rw-------  1 root root   68G Dec 28 10:12 disk-flat.vmdk

Що це означає: Це класичний descriptor + flat extent. Маленький disk.vmdk — дескриптор; великий файл — дані. Якщо ви скопіювали лише дескриптор, ви скопіювали етикетку, а не диск.

Рішення: Тримайте обидва файли разом. Не перейменовуйте один без редагування дескриптора. Ставтесь до них як до пари.

Завдання 2: Проінспектуйте файл-дескриптор (якщо існує)

cr0x@server:~$ sed -n '1,120p' /mnt/incoming/vmware-export/disk.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 142606336 VMFS "disk-flat.vmdk"

# The Disk Data Base
ddb.virtualHWVersion = "13"
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "8874"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.toolsInstallType = "4"

Що це означає: Рядок extent показує розмір (в секторах) і файл-основу. parentCID та CID підказують про відносини зі снапшотами. adapterType важливий для завантаження після імпорту (PVSCSI vs LSI vs SATA).

Рішення: Якщо parentCID не схожий на ffffffff і у вас є дельти снапшотів, зупиніться і знайдіть ланцюг. Конвертація невірного посилання — як отримати «завантажується, але дані відсутні».

Завдання 3: Запитайте у qemu-img, що він думає про файл

cr0x@server:~$ qemu-img info /mnt/incoming/vmware-export/disk.vmdk
image: /mnt/incoming/vmware-export/disk.vmdk
file format: vmdk
virtual size: 68 GiB (72980889600 bytes)
disk size: 68 GiB
cluster_size: 65536
Format specific information:
    cid: 4294967294
    parent cid: 4294967295
    create type: vmfs
    extents:
        [0]:
            virtual size: 68 GiB
            filename: /mnt/incoming/vmware-export/disk-flat.vmdk
            format: FLAT

Що це означає: qemu-img бачить його як VMDK і знайшов flat extent. Добре. Якщо тут помилка, ваша конвертація також зазнає невдачі.

Рішення: Якщо extents відсутні або filename вказує кудись ще, спочатку виправте проблеми з шляхами (часто файл flat переміщено/перейменовано).

Завдання 4: Перевірте, що ви випадково не маєте справи з ланцюгом снапшотів

cr0x@server:~$ find /mnt/incoming/vmware-export -maxdepth 1 -type f -name "*.vmdk" -printf "%f\n" | sort
disk-flat.vmdk
disk.vmdk

Що це означає: Лише два файли. Ймовірно, в цьому експорті немає ланцюга снапшотів. У ланцюгу ви б побачили файли на кшталт -000001.vmdk та подібні.

Рішення: Якщо ви бачите delta-диски, визначте активний «поточний» дескриптор і переконайтеся, що всі батьки присутні перед конвертацією.

Завдання 5: Перевірте вільне місце файлової системи, де буде виконуватись конвертація

cr0x@server:~$ df -h /mnt/convert
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  650G  63% /mnt/convert

Що це означає: У вас є 650G вільних. Конвертація тонкого 68G диска у товстий формат може розширитись. Навіть QCOW2 може розростися під час конвертації залежно від опцій і структури джерела.

Рішення: Плануйте гірший випадок по місцю. Якщо сумніваєтесь: конвертуйте у raw прямо на блочне зберігання (LVM-thin/ZFS), замість створення великого проміжного файлу.

Завдання 6: Заміряйте продуктивність сховища, перш ніж звинувачувати qemu-img

cr0x@server:~$ fio --name=readtest --filename=/mnt/convert/.fiotest --size=2G --direct=1 --rw=read --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based --group_reporting
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
Starting 1 process
readtest: Laying out IO file (1 file / 2048MiB)
Jobs: 1 (f=1): [R(1)][100.0%][r=965MiB/s][r=965 IOPS][eta 00m:00s]
read: IOPS=952, BW=952MiB/s (998MB/s)(27.9GiB/30001msec)
    clat (usec): min=402, max=10231, avg=1032.11, stdev=210.44

Що це означає: У вас приблизно 950 MiB/s послідовного читання. Якщо конвертація повзе зі швидкістю 40 MiB/s, вузьке місце не в «повільному диску» загалом — воно десь в іншому місці (шлях запису, CPU, однопоточна поведінка, стиснення, мережа).

Рішення: Зафіксуйте базову швидкість читання/запису. Це стане в пригоді, коли хтось скаже «Proxmox повільний».

Жарт #1: Ланцюг снапшотів VMDK нагадує корпоративну організаційну схему: усе здається стабільним, поки ви не запитаєте, хто насправді володіє даними.

Основні шаблони конвертації з qemu-img (і чому)

qemu-img — це робоча конячка для конвертацій форматів. Критичні рішення — це вибір:

• Формату виходу: qcow2 або raw (іноді raw — розумніший вибір).
• Поведінки алокації: sparse проти попереднього виділення (preallocated).
• Характеристик I/O: налаштування кешу та aio, що можуть прискорити конвертацію без брехні щодо стійкості.

Завдання 7: Попередній запуск розуміння з info на джерелі й планований вихід

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Що це означає: Вивід JSON зручний для скриптів і перевірок здорового глузду. virtual-size важливий; actual-size показує, наскільки великий файл зараз (для flat extents це може збігатися з virtual size).

Рішення: Вирішіть, чи зберігаєте тонку поведінку (thin), чи переходите в товсту. Для більшості міграцій залишайте thin, якщо немає причин інакше.

Завдання 8: Конвертація VMDK у QCOW2 (адекватні налаштування)

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
    (0.00/100%)
    (12.34/100%)
    (54.87/100%)
    (100.00/100%)

Що це означає: -p показує прогрес. Це базовий варіант. Без модних прапорів кешування. Це буде коректно, але може бути не найшвидше.

Рішення: Використовуйте це для одиничних завдань або коли не можна ризикувати хитрощами. «Нудно й правильно» — валідна операційна стратегія.

Завдання 9: Перевірте цілісність результату (read-only перевірка)

cr0x@server:~$ qemu-img check -r all /mnt/convert/disk.qcow2
No errors were found on the image.
443392/443392 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 72985100288

Що це означає: qemu-img check валідує структуру QCOW2. «No errors» — це те, чого ви хочете. Якщо бачите refcount errors, це червона сигнальна лампа.

Рішення: Якщо check повідомляє про корупцію, не імпортуйте. Переконвертуйте з джерела. Якщо корупція повторюється, підозрюйте проблеми з ланцюгом джерела або помилки зберігання.

Завдання 10: Перегляньте метадані QCOW2, щоб зрозуміти, що ви отримали

cr0x@server:~$ qemu-img info /mnt/convert/disk.qcow2
image: /mnt/convert/disk.qcow2
file format: qcow2
virtual size: 68 GiB (72980889600 bytes)
disk size: 12.4 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Що це означає: Virtual size — 68 GiB, а disk size — 12.4 GiB: тонкий/сипарс результат. Чудово для економії місця; не завжди добре для послідовної записної продуктивності, якщо навантаження відразу заповнить диск.

Рішення: Якщо навантаження — база даних, яка одразу алокує багато простору, розгляньте стратегії попереднього виділення або raw на блочному сховищі.

Завдання 11: Швидша конвертація з безпечнішими настройками кешу

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk-fast.qcow2
    (0.00/100%)
    (33.21/100%)
    (71.09/100%)
    (100.00/100%)

Що це означає: -t — режим кешу джерела; -T — режим кешу призначення. none зазвичай уникнути подвійного кешування і може зменшити накладні витрати. Це не зробить повільне сховище швидким; це лише зменшує марне буферизацію.

Рішення: Використовуйте це, коли контролюєте хост і довіряєте стеку зберігання. Якщо записуєте на ненадійне мережеве сховище, краще обрати безпечніший кеш за рахунок швидкості.

Завдання 12: Конвертація у raw (часто кращий варіант для Proxmox на ZFS/LVM-thin)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.raw
    (0.00/100%)
    (25.00/100%)
    (62.50/100%)
    (100.00/100%)

Що це означає: Raw — простий. Без таблиць метаданих. Мінімальні накладні витрати. На блочно-підтримуваних сховищах Proxmox raw часто перемагає за латентністю і передбачуваністю.

Рішення: Якщо ціль Proxmox — ZFS zvol або LVM-thin, наполегливо розгляньте імпорт як raw у ці бекенди замість того, щоб зберігати QCOW2 файл.

Завдання 13: Конвертація з явним subformat, коли qemu-img помиляється в угадуванні

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o subformat=qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
qemu-img: warning: -o subformat=qcow2 is not supported for output format qcow2

Що це означає: Це навмисний приклад «не робіть так». qemu-img скаже вам, коли ви намагаєтесь використовувати безглузді опції. Люди копіюють випадкові прапори зі старих дописів — інструмент не сентиментальний.

Рішення: Якщо ви не знаєте, що робить опція, не використовуйте її в вікні міграції. Дотримуйтеся прапорів, які можете пояснити під тиском.

Імпорт у Proxmox так, як подобається Proxmox

Конвертація — лише половина роботи. Потрібно ще правильно прикріпити диск: правильна шина, коректний порядок завантаження, правильний тип сховища і гостьова ОС, що може знайти свій кореневий пристрій.

Завдання 14: Перегляньте типи сховищ Proxmox і оберіть правильну ціль

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        100.0G           22.3G           72.6G   22.30%
local-lvm     lvmthin     active        800.0G          312.0G          488.0G   39.00%
zfspool          zfs     active          1.7T           840.0G          860.0G   49.41%

Що це означає: dir сховища типу local можуть містити QCOW2 файли. lvmthin і zfs зазвичай хочуть raw томи (хоча Proxmox може зберігати qcow2 на деяких бекендах; зазвичай ви пожалкуєте про це на блочному сховищі).

Рішення: Якщо імпортуєте в local-lvm або zfspool, плануйте raw імпорт або дозвольте Proxmox конвертувати під час імпорту.

Завдання 15: Створіть каркас ВМ (поки без диска), потім імпортуйте диск

cr0x@server:~$ qm create 120 --name vm-imported --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
created VM 120

Що це означає: Тепер у вас є конфіг ВМ, до якого можна прикріпити диск.

Рішення: Виберіть VirtIO для NIC, якщо лише гостьова ОС не позбавлена драйверів. Якщо це Windows без драйверів VirtIO, плануйте ін’єкцію драйверів або почніть з e1000 і мігруйте пізніше.

Завдання 16: Імпорт QCOW2 файлу в сховище Proxmox

cr0x@server:~$ qm importdisk 120 /mnt/convert/disk.qcow2 local-lvm
importing disk 'unused0:local-lvm:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 10.2 GiB of 68.0 GiB (15.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-120-disk-0'

Що це означає: Proxmox імпортував в local-lvm і, ймовірно, конвертував у raw том під капотом. Диск з’являється як unused0, поки ви його не приєднаєте.

Рішення: Прикріпіть його до правильного контролера (VirtIO SCSI для сучасних Linux/Windows з драйверами; SATA/IDE лише для сумісності).

Завдання 17: Прикріпіть імпортований диск і встановіть порядок завантаження

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-120-disk-0 --boot order=scsi0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-lvm:vm-120-disk-0 -boot order=scsi0

Що це означає: Диск тепер є завантажувальним пристроєм на контролері VirtIO SCSI — загалом хороший вибір для продуктивності й можливостей (discard, queueing).

Рішення: Якщо гість не завантажується, а раніше використовував LSI Logic у VMware, тимчасово спробуйте --scsihw lsi, щоб підняти його, потім мігруйте на VirtIO.

Завдання 18: Перевірте конфіг ВМ, включно з типом машини та BIOS/UEFI

cr0x@server:~$ qm config 120
boot: order=scsi0
cores: 4
memory: 8192
name: vm-imported
net0: virtio=BC:24:11:8A:19:FE,bridge=vmbr0
scsi0: local-lvm:vm-120-disk-0,iothread=1
scsihw: virtio-scsi-pci

Що це означає: Шукайте відсутній bios / efidisk0, якщо оригінальна ВМ використовувала UEFI. Якщо вона була UEFI у VMware, а ви завантажуєте з SeaBIOS — очікуйте проблем.

Рішення: Підлаштуйте прошивку: якщо UEFI — встановіть --bios ovmf і додайте EFI диск. Якщо legacy — залишайте SeaBIOS.

Завдання 19: Конвертація «на льоту» через Proxmox, якщо хочете менше кроків

cr0x@server:~$ qm importdisk 120 /mnt/incoming/vmware-export/disk.vmdk zfspool
importing disk 'unused0:zfspool:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:zfspool:vm-120-disk-0'

Що це означає: Proxmox може імпортувати напряму з VMDK у обране сховище, конвертуючи за потреби. Це зменшує проміжні файли і шанс забути прибрати. Також це концентрує ризик на вузлі Proxmox, що виконує роботу.

Рішення: Якщо робите так, запускайте на вузлі з запасом ресурсів і стабільним сховищем. Не виконуйте великі конвертації на вузлі, що вже перенавантажений під прод.

Налаштування продуктивності: швидко без самосаботажу

Швидкість конвертації визначається кількома нудними обмеженнями: пропускна здатність читання, пропускна здатність запису, CPU (для контрольних сум/метаданих) і макет джерельного формату. QCOW2 додає накладні метадані; ланцюги снапшотів VMDK додають випадкові читання. А мережеве сховище додає латентність, яка перетворює послідовні записи на повільний документальний фільм.

Знайте, що ви оптимізуєте

• Швидкий час конвертації: мінімізуйте CPU накладні, уникайте подвійного кешування, записуйте послідовно на швидке локальне сховище, потім переміщуйте.
• Швидкий час роботи ВМ: оберіть правильний фінальний формат і бекенд; raw на блочному сховищі важко перемогти.
• Економія місця: QCOW2 sparse — добре; стиснення може допомогти, але додає CPU і може погіршити латентність пізніше.

Завдання 20: Заміряйте CPU як вузьке місце під час конвертації

cr0x@server:~$ pidstat -dru -p $(pgrep -n qemu-img) 1
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

11:04:12      UID       PID    %usr %system  %CPU   CPU  kB_rd/s kB_wr/s  Command
11:04:13        0     44122   85.00   10.00 95.00     7  980000.00 420000.00 qemu-img

Що це означає: Якщо %CPU завантажений, а I/O ставки нижчі, ніж може надати сховище, ви CPU-bound — часто через обробку метаданих QCOW2 або складність джерела.

Рішення: Якщо CPU — вузьке місце, розгляньте конвертацію в raw, роботу на потужнішому вузлі або відмову від стиснення/шифрування. Не чекайте, що прапори кешу вирішать обмеження CPU.

Завдання 21: Підтвердіть I/O wait, коли конвертація «повільна»

cr0x@server:~$ iostat -xm 1 3
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    6.11   52.40    0.00   23.29

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         220.0  880000.0     0.0   0.00    1.10  4000.0    160.0  640000.0     0.0   0.00    2.80  4000.0    0.70  78.00

Що це означає: Високий %iowait плюс висока завантаженість пристрою означає, що вузьке місце — ваше сховище. Якщо util низький, але iowait високий — підозрюйте мережеве сховище або блокування/латентність файлової системи.

Рішення: Перенесіть конвертацію на швидший локальний scratch і потім імпортуйте. Або, якщо призначення — повільна частина, оберіть кращий бекенд (local-lvm/zfs на SSD) для імпорту.

Завдання 22: Використовуйте локальний scratch шлях, щоб уникнути запису QCOW2 по NFS

cr0x@server:~$ mount | grep -E 'nfs|cifs'
nas01:/exports/vm-migrations on /mnt/incoming type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Що це означає: Джерело на NFS. Читання часто ОК; запис результатного QCOW2 назад на NFS — ось де продуктивність іде погано.

Рішення: Скопіюйте джерело локально, конвертуйте локально, потім імпортуйте. Так, це додаткові кроки. Ні, ви не пожалкуєте.

Завдання 23: Скопіюйте VMDK локально, зберігаючи sparse (коли доречно)

cr0x@server:~$ rsync -aH --sparse --info=progress2 /mnt/incoming/vmware-export/ /mnt/local-scratch/vmware-export/
         68,000,000,000 100%  720.00MB/s    0:01:30 (xfr#2, to-chk=0/3)

Що це означає: --sparse може зберегти діри в файлах на файлових системах, які це підтримують, що важливо для тонких образів.

Рішення: Якщо джерело реально flat/thick, sparse не допоможе. Але це й не сильно шкодить; тримайте це в стандартній процедурі міграції.

Завдання 24: Попередньо виділіть вихід, коли дбаєте про стабільну продуктивність запису пізніше

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o preallocation=metadata /mnt/local-scratch/vmware-export/disk.vmdk /mnt/convert/disk-prealloc.qcow2
    (0.00/100%)
    (49.00/100%)
    (100.00/100%)

Що це означає: preallocation=metadata виділяє метадані QCOW2 наперед, зменшуючи частину алокаційного шуму пізніше без повного попереднього виділення всіх кластерів даних.

Рішення: Використовуйте, коли гість буде багато випадково записувати на початку (бази даних, зайняті сервери додатків). Якщо місця мало — уникайте повного preallocation.

Завдання 25: Переконайтесь, що ви випадково не створили гігантський товстий QCOW2

cr0x@server:~$ du -h /mnt/convert/disk-prealloc.qcow2
13G	/mnt/convert/disk-prealloc.qcow2

Що це означає: Все ще відносно малий: добре. Якщо він рівний virtual size — ви зробили його товстим.

Рішення: Якщо ненавмисно зробили thick, перезапустіть конвертацію з правильними опціями або розгляньте raw на блочному сховищі.

Завдання 26: Підтвердіть очікування discard/TRIM (для тонких бекендів)

cr0x@server:~$ qm set 120 --scsi0 local-lvm:vm-120-disk-0,discard=on
update VM 120: -scsi0 local-lvm:vm-120-disk-0,discard=on

Що це означає: Увімкнення discard в гості (де підтримується). На тонкопровізіонованих бекендах це може повертати звільнені блоки. На деяких стосах це нічого не робить; на інших це допомагає тримати пул здоровим.

Рішення: Увімкніть для Linux-гостей з fstrim і сучасними ядрами. Для деяких Windows-налаштувань перевірте поведінку перед тим, як робити припущення.

Жарт #2: Увімкнути всі «прапори продуктивності» одразу — це як додати вісім спойлерів до седану: технічно модифіковано, все ще повільно, тепер гучніше.

Швидкий план діагностики (знайдіть вузьке місце за хвилини)

Ось порядок, який я використовую, коли конвертація або продуктивність першого завантаження виглядає неправильно. Це уникає зайвих глибин і дає конкретну відповідь «це CPU / це сховище / це мережа / це конфіг гостя» швидко.

Перше: доведіть, що образ-джерело когерентний

1. qemu-img info на VMDK. Якщо він падає — зупиніться; виправте дескриптор/extent/снапшоти.
2. Перелік директорії на предмет відсутніх delta-файлів або перейменованих extents.
3. Якщо є ланцюг снапшотів, ідентифікуйте активний дескриптор (той, що використовувала ВМ) і переконайтеся, що всі батьки є.

Друге: знайдіть обмеження пропускної здатності

1. Заміри швидкості запису на призначення за допомогою fio або хоча б спостереження iostat -xm.
2. Перевірте, чи конвертація CPU-bound за допомогою pidstat.
3. Якщо джерело — мережеве сховище, скопіюйте локально й повторіть конвертацію, щоб відокремити мережу від накладних витрат конвертації.

Третє: провалідуйте вихід і прикріплення у Proxmox

1. qemu-img check на QCOW2 (або перевірте розмір raw і контрольні суми, якщо можливо).
2. qm config: правильний контролер, порядок завантаження, відповідність BIOS/UEFI.
3. Драйвери в гості: присутні VirtIO драйвери для диска/NIC? Якщо ні, очікуйте помилок завантаження або відсутніх мереж.

Завдання 27: Підтвердіть, чи ви CPU-bound або I/O-bound одним поглядом

cr0x@server:~$ top -b -n 1 | head -n 15
top - 11:06:01 up 10 days,  2:14,  2 users,  load average: 9.12, 8.44, 7.90
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 61.3 us,  7.2 sy,  0.0 ni,  8.4 id, 23.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem : 128000.0 total,  24000.0 free,  12000.0 used,  92000.0 buff/cache
MiB Swap:  16000.0 total,  15950.0 free,     50.0 used. 108000.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
44122 root      20   0  221668  29384   6120 R  298.0   0.0   1:22.19 qemu-img

Що це означає: Високе CPU (qemu-img використовує кілька ядер) плюс високий wa (I/O wait) означає, що ви обмежені в обох; прості прапори qemu-img не виправлять повільний диск.

Рішення: Перенесіть роботу на швидше сховище або заплануйте її, коли сховище менш завантажене. Якщо це неможливо, конвертуйте в raw і дайте бекенду обробляти алокацію.

Типові помилки: симптом → корінь проблеми → виправлення

Цей розділ написаний мовою чергового: що ви бачите, що це зазвичай означає і що насправді працює.

1) qemu-img: «Could not open ‘…’: invalid VMDK descriptor»

Симптоми: qemu-img info або convert одразу падає з помилками парсингу дескриптора.

Корінь проблеми: Файл-дескриптор пошкоджений, неправильно відредагований, проблеми з newline/encoding або він посилається на відсутній/перейменований extent файл.

Виправлення:

• Відкрийте дескриптор і перевірте, чи ім’я extent-файлу відповідає тому, що є на диску.
• Переконайтеся, що flat extent існує і читається.
• Якщо дескриптор загублено, але у вас є *-flat.vmdk, акуратно реконструюйте дескриптор або ре-експортуйте з VMware.

2) Конвертація «успішна», але ВМ завантажується в initramfs / не знаходить кореневий пристрій

Симптоми: Linux падає в аварійну оболонку; після імпорту кореневий пристрій не знайдено.

Корінь проблеми: Змінився контролер диска (наприклад, VMware LSI Logic → Proxmox VirtIO SCSI) і initramfs не має драйверів, або fstab використовує імена пристроїв, що змінилися (sda vs vda).

Виправлення:

• Тимчасово переключіть контролер на сумісніший (наприклад, LSI), щоб завантажитись, потім встановіть драйвери VirtIO і перебудуйте initramfs.
• Використовуйте UUID у fstab і конфігурації завантажувача, якщо можливо.

3) Windows BSOD після імпорту (INACCESSIBLE_BOOT_DEVICE)

Симптоми: BSOD відразу після імпорту в Proxmox.

Корінь проблеми: У Windows немає драйвера контролера зберігання для нового віртуального контролера (VirtIO SCSI) або невідповідність режиму завантаження (UEFI vs BIOS).

Виправлення:

• Завантажуйте з контролером, який Windows вже підтримує (SATA, LSI).
• Встановіть VirtIO драйвери всередині Windows, потім переключіться на VirtIO.
• Збійте режим прошивки і перевірте порядок завантаження.

4) Конвертація надзвичайно повільна на NFS/CIFS

Симптоми: Конвертація працює десятки MB/s незважаючи на швидкі локальні диски.

Корінь проблеми: Запис виходу через мережеве сховище з високою латентністю; оновлення метаданих QCOW2 підсилюють маленькі записи.

Виправлення: Стадіюйте локально (NVMe scratch), конвертуйте локально, потім імпортуйте у фінальний бекенд. Якщо потрібно писати через мережу, надавайте перевагу raw і більшим I/O, і прийміть, що це все одно може бути повільно.

5) Імпортований диск — «unused0» і ВМ не завантажується

Симптоми: Диск присутній у сховищі Proxmox, але не прикріплений як завантажувальний пристрій.

Корінь проблеми: qm importdisk імпортує, але не прикріплює; порядок завантаження не встановлений.

Виправлення: Прикріпіть диск за допомогою qm set і встановіть --boot order=....

6) Розмір диска виглядає неправильно після конвертації

Симптоми: Файл QCOW2 має розмір, рівний virtual size, коли ви очікували thin, або навпаки.

Корінь проблеми: Опції preallocation, джерело був thick flat extent, або шлях конвертації розширив дані (нулі перетворились на алоковані блоки).

Виправлення: Повторно конвертуйте з потрібними опціями; для тонких цілей переконайтесь у використанні sparse-дружніх методів копіювання і уникайте інструментів, що деспарсуюють (деякі прості копії це роблять).

7) «Failed to get write lock» / «image is in use» під час конвертації

Симптоми: qemu-img відмовляється писати або Proxmox не може стартувати ВМ.

Корінь проблеми: Файл диска відкритий іншим процесом (завдання бекапу, інша конвертація, ВМ все ще посилається на нього).

Виправлення: Знайдіть процес, що тримає файл/том, і зупиніть його; уникайте конвертації «на місці» на активному datastore.

Завдання 28: Знайдіть, хто відкрив файл диска (класичне «чому заблоковано?»)

cr0x@server:~$ lsof /mnt/convert/disk.qcow2 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
qemu-img 44122 root    3u   REG   8,17 13314398624 131073 /mnt/convert/disk.qcow2

Що це означає: Файл активно відкрито qemu-img. Якщо бачите qemu-system-x86_64, то ВМ його використовує.

Рішення: Не боріться з блокуваннями. Акуратно зупиніть споживача, потім продовжуйте.

Три корпоративні міні-історії (бо диску байдуже до ваших почуттів)

Міні-історія 1: Інцидент через неправильне припущення

Команда мала експорт VMware: акуратний server.vmdk у спільній папці. Хтось скопіював лише цей файл на вузол Proxmox і запустив qemu-img convert. qemu-img скаржився на відсутні extents. Вони знизали плечима і переекспортували, отримали те саме, потім вирішили, що інструмент «примхливий».

Неправильне припущення було простим: вони думали, що VMDK завжди само-повний. У їхньому середовищі ESXi зберігав дескрипторний файл поруч із величезним flat файлом, а їхній робочий процес експорту зберігав обидва — але лише дескриптор виглядав «важливим». Великий -flat.vmdk стояв поруч мовчазний співучасник.

Зрештою вони скопіювали flat extent також, і конвертація спрацювала. Але потім ВМ завантажилась із помилками файлової системи. Справжня шкода сталася раніше: під час першої спроби вони намагалися «виправити» дескриптор, редагуючи розмір extent і ім’я файлу наосліп, потім конвертували з невідповідним дескриптором, що вказував на інший flat файл із старішого експорту. Конвертація була коректною — коректною щодо неправильного джерела.

Виправлення не було героїчним. Вони почали з оригінального експорту, перевірили extent у дескрипторі, перевірили контрольні суми обох файлів і лише потім запустили конвертацію. Просто, але дорога помилка: ніколи не редагуйте метадані образу, якщо не можете довести, що робите.

Міні-історія 2: Оптимізація, що дала протилежний ефект

Інша група щодня виконувала міграції для оновлення лабораторії. Вони хотіли швидкості. Знайшли кілька прапорів в інтернеті і зробили скрипт «turbo convert»: агресивні режими кешу, паралельні роботи і запис напряму на мережеву шару, щоб «уникнути зайвого копіювання».

Було швидко — поки не стало повільно. Деякі конвертації давали QCOW2, які проходили поверхневий qemu-img info, але пізніше падали під навантаженням із попередженнями про корупцію. Інші завантажувалися, але мали тонкі помилки додатків, які виглядали як баги ПЗ. Міграції стали нічним кошмаром підтримки: кожна імпортована ВМ була під сумнівом.

Провал переважно полягав у семантиці стійкості. Вони змішали кеш-опції з поведінкою мережевого сховища і трактували «конвертація завершена» як «байти безпечно записані». Мережеві глюки і серверне кешування означали, що робота могла завершитися, поки сховище ще не підтвердило реального збереження, на яке команда розраховувала.

Вони відкотили wrapper. Новий процес виглядав повільнішим на папері, але закінчувався швидше в кінцевому підсумку, оскільки припинив виробляти браковані артефакти: стадіюйте локально, конвертуйте локально з консервативним кешем, валідуйте qemu-img check, потім імпортуйте. Найкраща оптимізація — усунути переробки.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Система, пов’язана з фінансами, мігрувала з VMware у Proxmox у тісні терміни. Команда зробила щось фундаментально немодне: вони написали чеклист і суворо його дотримувалися. Не «приємний» чеклист. Контрольний чеклист, який відмовлявся рухатися далі, поки кожен крок не дав очікуваний результат.

Вони зберегли qemu-img info JSON для кожного джерела, прив’язали його до заявки на міграцію і записали конфіг Proxmox після імпорту. Вони також запускали qemu-img check на кожному QCOW2 артефакті і тримали лог. Це було нудно, як це часто буває в добрих операціях.

Під час cutover одна ВМ не завантажилася. Ніякої паніки. Вони порівняли оригінальний тип адаптера в дескрипторі (lsilogic) з конфігом Proxmox (VirtIO SCSI). Переключили контролер на LSI, завантажилися, встановили драйвери VirtIO, переключили назад і рухалися далі. Чеклист не уникнув проблеми, але він запобіг хаосу.

Що врятувало день — не хитра команда. Це дисциплінована спостережуваність: кожен крок залишав докази. Коли щось ламалося, вони не гадали — вони порівнювали.

Контрольні списки / покроковий план

Використовуйте один із них в залежності від вашого бекенду зберігання і готовності до проміжних файлів.

План A: Безпечно й портативно (VMDK → QCOW2 файл → імпорт)

1. Перелік файлів: впевніться, що у вас є дескриптор + flat extent (або один монолітний VMDK).
2. Запустіть qemu-img info на джерелі; підтвердіть virtual size і extents.
3. Перевірте вільне місце на файловій системі для конвертації (планування гіршого випадку).
4. Стадіюйте локально, якщо джерело/ціль — мережеве сховище.
5. Конвертуйте з консервативними прапорами: qemu-img convert -p -f vmdk -O qcow2.
6. Запустіть qemu-img check -r all на QCOW2.
7. Створіть каркас ВМ у Proxmox: qm create.
8. Імпортуйте диск: qm importdisk у вибране сховище.
9. Прикріпіть диск і встановіть порядок завантаження: qm set.
10. Перша валідація завантаження: переконайтеся, що ОС бачить диск, NIC працює, синхронізація часу й сервіси стартують.

План B: Орієнтований на Proxmox (імпорт напряму з VMDK)

1. Підтвердіть джерело VMDK за допомогою qemu-img info.
2. Створіть каркас ВМ з правильними очікуваннями прошивки (UEFI vs BIOS, наскільки відомо).
3. Запустіть qm importdisk VMID disk.vmdk STORAGE.
4. Прикріпіть диск до правильного контролера і встановіть порядок завантаження.
5. Завантажте, валідуйте, потім акуратно налаштуйте опції продуктивності (iothread, discard, cache).

План B підходить для рутинних міграцій, коли ви довіряєте здоров’ю вузла Proxmox і хочете менше артефактів для керування. План A краще, коли потрібен портативний QCOW2 і відтворювана аудиторія.

Завдання 29: Зафіксуйте відтворюваний «запис конвертації» (дешевий аудит)

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk | tee /mnt/convert/disk.vmdk.info.json
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Що це означає: Ви зберегли машино-зчитуваний запис про те, що конвертували. Це допомагає уникнути питання «що ми імпортували знову?» через два тижні.

Рішення: Зберігайте ці записи з тикетами змін. Це нудно. Але працює.

Завдання 30: Підтвердіть, що імпортований диск існує на цільовому сховищі

cr0x@server:~$ pvesm list local-lvm | grep vm-120-disk-0
local-lvm:vm-120-disk-0  vm-120-disk-0  68.00G

Що це означає: Том присутній і має коректний розмір.

Рішення: Якщо розмір неправильний, зупиніться і розслідуйте перед запуском. Неправильний розмір може вказувати на імпорт неправильного файлу або обрізані дані.

Завдання 31: Запустіть ВМ і спостерігайте раннє завантаження з боку хоста

cr0x@server:~$ qm start 120
started VM 120

Що це означає: ВМ запущена. Тепер потрібна видимість консолі.

Рішення: Якщо старт відразу невдалий, перевірте журнали задач Proxmox і помилки сховища. Якщо ВМ запускається, але не завантажується — перевірте невідповідність прошивки/контролера.

Цитата, яка має бути в кожному runbook міграції

Надія — не стратегія. — General Gordon R. Sullivan

FAQ

1) Чи конвертувати у QCOW2 чи raw для Proxmox?

Якщо ваша ціль — dir/NFS і ви хочете переносимий файл, QCOW2 підходить. Якщо ціль — LVM-thin або ZFS, raw зазвичай швидший і простіший. Якщо наполягаєте на QCOW2 на блочному сховищі — ви платите накладні за можливості, якими, ймовірно, не будете користуватись.

2) Чи може Proxmox імпортувати VMDK напряму?

Так, qm importdisk може імпортувати з VMDK у цільове сховище Proxmox, конвертуючи за потреби. Це зручно, але не замінює перевірку джерела й правильного прикріплення диска.

3) Чому qemu-img каже «invalid VMDK descriptor»?

Зазвичай дескриптор посилається на flat extent файл, який відсутній, перейменований або знаходиться в іншому шляху. Іноді дескриптор пошкоджений або неправильно відредагований. Перевірте ім’я extent і наявність flat файлу.

4) Мій сконвертований диск завантажується, але дані відсутні. Чому?

Ймовірно, ви конвертували невірний шар з ланцюга снапшотів (батько замість активного чилда), або не включили всі delta-файли. Ланцюги снапшотів VMware мають бути повними і консистентними, щоб конвертація відображала поточний стан.

5) Чому конвертація повільніша за просте копіювання файлу?

Конвертація може включати оновлення метаданих (QCOW2), випадкові читання (ланцюги снапшотів) або підсилення мережевої латентності (запис QCOW2 на NFS). Копіювання часто послідовне і простіше.

6) Чи потрібно переживати про UEFI vs BIOS під час імпорту?

Так. Якщо ВМ була UEFI у VMware, а ви завантажуєте її з legacy BIOS у Proxmox, ви отримаєте не-завантажувану систему, яка виглядає як «проблеми з диском», але ними не є. Підлаштуйте прошивку зарані.

7) Який найнадійніший крок перевірки після конвертації?

Запустіть qemu-img check -r all для структурної цілісності QCOW2, а потім зробіть тестове завантаження в ізольованій мережі. Перевірки цілісності не ловлять усіх проблем на рівні файлової системи, але виявляють корупцію образу.

8) Чи можу я прискорити конвертацію за допомогою стиснення QCOW2?

Можете, але це компроміс. Стиснення витрачає CPU і може погіршити латентність при випадковому I/O пізніше. Для продуктивних ВМ краще інвестувати в сховище, ніж у незрозумілу латентність.

9) Моя Windows ВМ не завантажується з VirtIO. Який найменш болісний шлях?

Завантажуйте з контролером, який Windows підтримує «з коробки» (зазвичай SATA/LSI), потім встановіть VirtIO драйвери всередині Windows і переключіться на VirtIO. Робіть це поетапно, а не одразу.

10) Де краще конвертувати — на вузлі Proxmox чи в іншому місці?

Конвертуйте там, де у вас стабільний I/O і запас ресурсів. Якщо вузли Proxmox зайняті, використайте виділений конвертаційний хост і потім імпортуйте. Краща міграція — та, що не конкурує з продукційними навантаженнями.

Практичні подальші кроки

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

Кроки, які дають негайний ефект:

• Запустіть qemu-img info на кожному VMDK, який плануєте мігрувати, і збережіть JSON-вивід із тикетом.
• Спочатку оберіть фінальну ціль зберігання (dir vs LVM-thin vs ZFS), потім вирішіть QCOW2 vs raw відповідно.
• Прийміть швидкий план діагностики: когерентність джерела → обмеження пропускної здатності → прикріплення у Proxmox.
• Стандартизуйте один шаблон конвертації на бекенд і припиніть імпровізації в час вікна змін.