Manpages

virt-v2v-input-vmware(1) — вхідні дані з VMware.

virt-v2v-input-xen(1) — вхідні дані з Xen.

virt-v2v-output-local(1) — виведення до локальних файлів або локальної libvirt.

virt-v2v-output-rhv(1) — виведення до oVirt або RHV.

virt-v2v-output-openstack(1) — виведення до OpenStack.

virt-v2v-release-notes-1.42(1) — Release notes for 1.42 release.

virt-v2v-release-notes-2.0(1) — Release notes for 2.0 release.

virt-v2v-release-notes-2.2(1) — Release notes for 2.2 release.

virt-v2v-release-notes-2.4(1) — Release notes for 2.4 release.

ПРИКЛАДИ

Перетворення з сервера vCenter VMware до локальної libvirt
Нехай маємо сервер vCenter VMware із назвою "vcenter.example.com", датацентр із назвою "Datacenter" і гіпервізор ESXi із назвою "esxi". Нам потрібно перетворити гостьову систему із назвою "vmware_guest" так, щоб її можна було запустити локально під керуванням libvirt.

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest

У цьому випадку, найімовірніше, вам доведеться запускати virt-v2v від імені користувача "root", оскільки програмі буде потрібен обмін даними із фоновою службою libvirt системи і копіювання дисків гостьової системи до /var/lib/libvirt/images.

Докладніші відомості: virt-v2v-input-vmware(1).

Перетворення з VMware до RHV/oVirt
Те саме, що і у попередньому прикладі, але з надсиланням гостьової системи до домену даних RHV за допомогою програмного інтерфейсу REST RHV. Інтерфейси мережі гостьової системи з’єднуються із мережею призначення із назвою "ovirtmgmt".

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \
-os ovirt-data -op /tmp/ovirt-admin-password -of raw \
-oo rhv-cafile=/tmp/ca.pem --bridge ovirtmgmt

У цьому випадку основна система, де запущено virt-v2v, працює як сервер перетворення.

Докладніші відомості: virt-v2v-output-rhv(1).

Перетворення з гіпервізору ESXi за допомогою SSH до локальної libvirt
Нехай маємо гіпервізор ESXi із назвою "esxi.example.com" і уможливленим доступом за допомогою SSH. Потрібно перетворити його зі сховища VMFS на сервері до локального файла.

virt-v2v \
-i vmx -it ssh \
"ssh://root [AT] esxi.com/vmfs/volumes/datastore1/guest/guest.vmx" \
-o local -os /var/tmp

Гостьову систему перед перетворенням має бути вимкнено. Потреби у запуску virt-v2v від імені користувача root у цьому випадку немає.

Докладніший опис перетворення файлів VMX наведено на сторінці virt-v2v-input-vmware(1).

Перетворення образу диска до формату OpenStack
Нехай маємо образ диска з іншого гіпервізору, який слід перетворити для запуску на OpenStack (підтримку передбачено лише для OpenStack на основі KVM). Тоді можна запустити virt-v2v у віртуальній машині OpenStack (яку ми називатимемо нижче "v2v-vm") ось так:

virt-v2v -i disk disk.img -o openstack -oo server-id=v2v-vm

Див. virt-v2v-output-openstack(1).

Перетворення образу диска на образ диска
Нехай маємо образ диска з іншого гіпервізору, який слід перетворити для запуску на KVM. Тоді можна піти одним зі двох шляхів. Найпростішим шляхом буде такий:

virt-v2v -i disk диск.img -o local -os /var/tmp

де virt-v2v має визначити усі параметри вхідного образу disk.img і (у цьому випадку) записати перетворений результат до /var/tmp.

Складнішим способом є створення XML libvirt із описом вхідної гостьової системи (якщо можна якось отримати XML libvirt з початкового гіпервізора, все стає набагато простішим). Далі, можна зробити так:

virt-v2v -i libvirtxml guest-domain.xml -o local -os /var/tmp

Оскільки guest-domain.xml містить шляхи до образів гостьової системи, вам не потрібно вказувати назву образу диска у рядку команди.

Щоб перетворити локальний образ диска і негайно завантажити його у локальному qemu, віддайте таку команду:

virt-v2v -i disk disk.img -o qemu -os /var/tmp -oo qemu-boot

ПАРАМЕТРИ

--help

Показати довідкове повідомлення.

--bandwidth біти_за_секунду
--bandwidth-file файл

Для деяких методів введення можна обмежити ширину каналу мережі, які вони використовуватимуть статично або динамічно. У першому варіанті встановлюється статичне обмеження ширини каналу у бітах за секунду. Можна використовувати формати, подібні до "10M" (означає 10 мегабітів за секунду).

У другому варіанті ширина каналу обмежується динамічно на основі вмісту файла (також у бітах за секунду у тих самих форматах, підтримку яких передбачено у першому варіанті). Ви можете використовувати обидва параметри разом, тобто: спочатку обмежити швидкістю статично, а потім ви можете створити файл вже під час роботи virt-v2v для коригування швидкості динамічно.

Підтримку передбачено лише для таких варіантів:

Параметри без додаткових повідомлень ігноруються для інших способів введення.

-b ...
--bridge ...

Див. --network нижче.

--block-driver virtio-blk
--block-driver virtio-scsi

When choosing a block driver for Windows guests, prefer "virtio-blk" or "virtio-scsi". The default is "virtio-blk".

Note this has no effect for Linux guests at the moment. That may be added in future.

--colors
--colours

Використовувати послідовності символів ANSI для розфарбовування повідомлень. Ці послідовності типово використовуються, якщо дані виводяться на термінал tty. Якщо дані, виведені програмою, спрямовуються до файла, послідовності визначення кольорів ANSI буде вимкнено, якщо ви не додасте до команди цей параметр.

--compressed

This is the same as -oo compressed.

--echo-keys

Типово, якщо virt-v2v попросить вас ввести ключ або пароль, програма не відтворюватиме введені символи на екрані. Якщо ви не боїтеся TEMPEST-нападів, або у вашій кімнаті нікого, окрім вас, немає, ви можете скористатися цим прапорцем, щоб бачити, які саме символи ви вводите.

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

-i disk

Встановити метод введення disk.

У цьому режимі ви можете читати образ диска віртуальної машини без метаданих. virt-v2v намагається визначити найкращі типові значення для метаданих. Ці значення, зазвичай, є адекватними, але ви можете додатково змінити їх (наприклад, змінити об’єм пам’яті або кількість віртуальних процесорів) за допомогою параметра -i libvirtxml. У цей спосіб може бути імпортовано лише гостьові системи, які використовують лише один диск.

-i libvirt

Встановити метод введення libvirt. Цей метод є типовим.

У цьому режимі вам слід вказати назву гостьової системи libvirt або UUID у рядку команди. Ви також можете вказати адресу з’єднання libvirt (див. -ic).

See "Starting the libvirt system instance" below.

-i libvirtxml

Встановити метод введення libvirtxml.

У цьому режимі вам слід передати за допомогою рядка команди файл XML libvirt. Цей файл буде прочитано для отримання метаданих (зокрема назви та обсягу пам’яті) щодо початкової гостьової системи, а також розташування дисків із вхідними даними. Див. "Мінімальний XML для параметра -i libvirtxml" нижче.

-i local

Те саме, що і -i disk.

-i ova

Встановити метод введення ova.

У цьому режимі ви можете читати файл OVA VMware. Virt-v2v прочитає файл маніфесту ova і перевірити томи vmdk на коректність (за контрольними сумами), а також проаналізує файл ovf, а потім виконає перетворення гостьової системи. Див. virt-v2v-input-vmware(1).

-i vmx

Встановити метод введення vmx.

У цьому режимі ви можете читати файл VMX VMware безпосередньо або за допомогою SSH. Такий режим корисний, якщо віртуальні машини VMware зберігаються на сервері NFS так, що їх можна змонтувати безпосередньо, або так, що можна отримати доступ за допомогою SSH до гіпервізору ESXi. Див. virt-v2v-input-vmware(1).

-ic адреса_libvirt

Вказати адресу з’єднання libvirt, яким слід скористатися під час читання гостьової системи. Використовується, лише якщо -i libvirt.

Можна використовувати лише локальні з’єднання libvirt, з’єднання vCenter VMware або віддалені з’єднання Xen RHEL 5. Інші віддалені з’єднання libvirt, загалом, не працюватимуть.

Див. також virt-v2v-input-vmware(1), virt-v2v-input-xen(1).

-if формат

Лише для -i disk. Цей параметр вказує формат образу диска вхідних даних. Для інших варіантів вхідних даних вам слід вказати формат вхідних даних у метаданих.

-io ПАРАМЕТР=ЗНАЧЕННЯ

Встановити параметри вхідних даних, пов’язані із поточним режимом обробки або пересилання вхідних даних. Щоб ознайомитися із короткою довідкою щодо цих параметрів, ви можете скористатися такою командою:

virt-v2v -it vddk -io "?"

-io vddk-libdir=LIBDIR

Встановити каталог бібліотеки VDDK. У цьому каталозі мають міститися підкаталоги із назвами include, lib64 тощо, але у аргументі параметра не повинно бути самої частини назви каталогу lib64.

У більшості випадків цей параметр потрібен, якщо використовується канал передавання -it vddk (VDDK). Щоб дізнатися більше, ознайомтеся зі сторінкою virt-v2v-input-vmware(1).

-io vddk-thumbprint=xx:xx:xx:...

Встановити відбиток віддаленого сервера VMware.

Цей параметр потрібен, якщо використовується канал передавання -it vddk (VDDK). Щоб дізнатися більше, ознайомтеся зі сторінкою virt-v2v-input-vmware(1).

-io vddk-config=НАЗВА_ФАЙЛА
-io vddk-cookie=КУКА
-io vddk-nfchostport=ПОРТ
-io vddk-port=ПОРТ
-io vddk-snapshot=SNAPSHOT-MOREF
-io vddk-transports=РЕЖИМ:РЕЖИМ:...

Якщо використовується режим VDDK, ці параметри передаються без змін до додатка nbdkit(1) VDDK. Будь ласка, зверніться до сторінки підручника щодо nbdkit-vddk-plugin(1). Не користуйтеся цим, якщо не певні щодо наслідків. Усі ці параметри є необов’язковими.

-ip назва_файла

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

-it ssh

Якщо використано -i vmx, вмикає передавання даних за допомогою SSH. Див. virt-v2v-input-vmware(1).

-it vddk

Використати VDDK VMware як канал передавання даних під час копіювання дисків вхідних даних Див. virt-v2v-input-vmware(1). Якщо ви скористаєтеся цим параметром, ймовірно, вам доведеться скористатися і іншими параметрами -io vddk* для визначення способу встановлення з’єднання за допомогою VDDK.

--key ВАРІАНТ

Specify a key for LUKS, to automatically open a LUKS device when using the inspection.
--key NAME:key:KEY_STRING
--key UUID:key:KEY_STRING
--key all:key:KEY_STRING

"NAME" is the libguestfs device name (eg. "/dev/sda1"). "UUID" is the device UUID. "all" means try the key against any encrypted device.

Використовувати вказаний "РЯДОК_КЛЮЧА" як пароль.

--key NAME:file:FILENAME
--key UUID:file:FILENAME
--key all:file:FILENAME

Прочитати пароль з файла НАЗВА_ФАЙЛА.

--key NAME:clevis
--key UUID:clevis
--key all:clevis

Attempt passphrase-less unlocking for the device with Clevis, over the network. Please refer to "ENCRYPTED DISKS" in guestfs(3) for more information on network-bound disk encryption (NBDE).

Note that if any such option is present on the command line, QEMU user networking will be automatically enabled for the libguestfs appliance.

--keys-from-stdin

Прочитати параметри ключа або пароля із джерела стандартного введення. Типово програма намагається читати паролі від користувача відкриттям /dev/tty.

Якщо зашифрованих пристроїв декілька, вам слід вказати декілька ключів у stdin, по одному у рядку.

Зауважте, що --keys-from-stdin стосується лише ключів і паролів до зашифрованих пристроїв і розділів, а не паролів, які використовуються для встановлення з’єднання із віддаленими серверами.

--mac aa:bb:cc:dd:ee:ff:network:out
--mac aa:bb:cc:dd:ee:ff:bridge:out

Прив’язка MAC-адреси NIC до мережі або містка.

Див. "Мережі і містки" нижче.

--mac aa:bb:cc:dd:ee:ff:ip:ipaddr[,gw[,len[,ns,ns,...]]]

Примусово використати для певного інтерфейсу (контрольованого за його MAC-адресою) статичну IP-адресу після завантаження.

Поля у параметрі є такими: "ipaddr" є IP-адресою; "gw" — необов’язкова IP-адреса шлюзу; "len" — довжина маски підмережі (ціле число). Останні параметри є нульовими або додатковими IP-адресами назв серверів.

Цей параметр можна не вказувати або вказувати довільну кількість разів.

Потреба у цьому параметрі виникає лише для деяких гостьових систем із помилками, зокрема Windows, які не здатні зберігати прив’язки MAC-адрес до статичних IP-адрес автоматично. Він вам не знадобиться, якщо Windows використовує DHCP. У поточній версії параметр ігнорується для гостьових систем Linux, оскільки у цих систем цієї проблеми немає.

--machine-readable
--machine-readable=формат

За допомогою цього параметра можна зробити виведені дані придатнішими для обробки комп’ютером, якщо для цієї обробки використовуються інші програми. Див. "Придатне до читання компʼютером виведення" нижче.

-n вхід:вихід
-n вихід
--network вхід:вихід
--network вихід
-b вхід:вихід
-b вихід
--bridge вхід:вихід
--bridge вихід

Пов’язати мережу (або місток) із назвою "вхід" із мережею (або містком) із назвою "вихід". Якщо не вказано префікс "вхід:", із "вихід" буде пов’язано усі інші мережі (або містки).

Див. "Мережі і містки" нижче.

-o disk

Те саме, що і -o local.

-o glance

Цей параметр є застарілим. Вам, ймовірно, слід скористатися замість нього параметром -o openstack.

Встановити метод виведення до OpenStack Glance. У цьому режимі перетворену гостьову систему буде вивантажено до Glance. Див. virt-v2v-output-openstack(1).

-o kubevirt

Set the output method to kubevirt. Note the way this mode works is experimental and will change in future.

In this mode, the converted guest is written to a local directory specified by -os /dir (the directory must exist). The converted guest’s disks are written to:

/каталог/назва-sda
/каталог/назва-sdb
[тощо]

and guest metadata is created in the associated YAML file:

/dir/name.yaml

де "назва" — назва гостьової системи.

-o libvirt

Встановити метод виведення libvirt. Цей метод є типовим.

У цьому режимі перетворену гостьову систему буде створено як гостьову систему libvirt. Ви також можете вказати адресу з’єднання libvirt (див. -oc).

See "Starting the libvirt system instance" below, and virt-v2v-output-local(1).

-o local

Встановити метод виведення до local.

У цьому режимі перетворену гостьову систему буде записано до локального каталогу, вказаного за допомогою параметра -os /каталог (каталог має існувати). Перетворені диски гостьової системи буде записано так:

/каталог/назва-sda
/каталог/назва-sdb
[тощо]

Також буде створено файл XML libvirt із метаданими гостьової системи:

/каталог/назва.xml

де "назва" — назва гостьової системи.

-o null

Встановити метод виведення до null.

The guest is converted and copied but the results are thrown away and no metadata is written.

-o openstack

Встановити метод виведення до OpenStack. Див. virt-v2v-output-openstack(1).

-o ovirt

Те саме, що і -o rhv.

-o ovirt-upload

Те саме, що і -o rhv-upload.

-o qemu

Встановити метод виведення до qemu.

Дія параметра подібна до -o local, але при виконанні команди програма записує скрипт командної оболонки, яким можна скористатися для завантаження гостьової системи у qemu. Перетворені диски і скрипт оболонки буде записано до каталогу, вказаного за допомогою параметра -os.

When using this output mode, you can also specify the -oo qemu-boot option which boots the guest under qemu immediately.

-o rhev

Те саме, що і -o rhv.

-o rhv

Встановити метод виведення до rhv.

Перетворену гостьову систему буде записано до домену сховища експортування RHV. Слід також вказати параметр -os для визначення розташування домену сховища експортування. Зауважте, що використання цього параметр не імпортує гостьову систему до RHV. Вам доведеться зробити це пізніше за допомогою інтерфейсу сховища.

Див. virt-v2v-output-rhv(1).

-o rhv-upload

Встановити метод виведення до rhv-upload.

Перетворену гостьову систему буде записано безпосередньо до домену даних RHV. Цей метод є швидшим за -o rhv, але потребує oVirt або RHV ≥ 4.2.

Див. virt-v2v-output-rhv(1).

-o vdsm

Встановити метод виведення до vdsm.

Цей режим подібний до -o rhv, але тут треба вказувати повний шлях до домену даних: /rhv/data-center/<uuid-датацентру>/<uuid-домену-даних>. Цей режим використовується, лише якщо virt-v2v запущено під керуванням VDSM.

-oa sparse
-oa preallocated

Встановити режим розміщення виведеного файла. Типовим режимом є "sparse" (розріджений файл).

-oc АДРЕСА

Вказати адресу з’єднання, якою слід скористатися під час записування перетвореної гостьової системи.

Для -o libvirt це адреса libvirt. Можна використовувати лише локальні з’єднання libvirt. Віддалені з’єднання libvirt не працюватимуть. Докладніший опис можна знайти на сторінці virt-v2v-output-local(1).

-of формат

Під час перетворення гостьової системи перетворити диски до вказаного формату.

Якщо не вказано, буде використано формат вхідних даних.

-on назва

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

-oo ПАРАМЕТР=ЗНАЧЕННЯ

Встановити параметри вихідних даних, пов’язані із поточним режимом виведення даних. Щоб ознайомитися із короткою довідкою щодо цих параметрів, ви можете скористатися такою командою:

virt-v2v -o rhv-upload -oo "?"

-oo compressed

For outputs which support qcow2 format (-of qcow2), this writes a compressed qcow2 file. It is the equivalent to the -c option of qemu-img(1).

-oo guest-id="ІДЕНТИФІКАТОР"

Лише для -o openstack (virt-v2v-output-openstack(1)). Встановити ідентифікатор гостьової системи, який буде збережено у кожному томі Cinder у властивості тому "virt_v2v_guest_id".

-oo qemu-boot

Лише якщо використовується -o qemu, негайно завантажує гостьову систему після завершення роботи virt-v2v.

-oo verify-server-certificate
-oo verify-server-certificate="true|false"

Лише для -o openstack (virt-v2v-output-openstack(1)). Цим параметром можна скористатися для вимикання процедури перевірки сертифікатів SSL під час встановлення з’єднання із OpenStack. Використовується -oo verify-server-certificate=false.

-oo os-*=*

Лише для -o openstack (virt-v2v-output-openstack(1)). Встановити параметри необов’язкового розпізнавання у OpenStack. Приклад: -oo os-username=ІМʼЯ є еквівалентом "openstack --os-username=ІМʼЯ".

-oo rhv-cafile=ca.pem

Лише для -o rhv-upload (virt-v2v-output-rhv(1)). Файл ca.pem (служби сертифікації), скопійований з /etc/pki/ovirt-engine/ca.pem у рушії oVirt.

-oo rhv-cluster="НАЗВА_КЛАСТЕРА"

Лише для -o rhv-upload (virt-v2v-output-rhv(1)). Встановити назву кластера RHV. Якщо не вказано, буде використано назву "Default".

-oo rhv-proxy

For -o rhv-upload (virt-v2v-output-rhv(1)) only, proxy the upload through oVirt Engine. This is slower than uploading directly to the oVirt node but may be necessary if you do not have direct network access to the nodes.

-oo rhv-verifypeer

Лише для -o rhv-upload (virt-v2v-output-rhv(1)). Перевірити автентичність сервера oVirt/RHV шляхом перевірки сертифіката сервера за допомогою служби сертифікації.

-oo server-id="НАЗВА|UUID"

Лише для -o openstack (virt-v2v-output-openstack(1)). Встановити назву базової системи перетворення, у якій буде запущено virt-v2v.

-oo vdsm-compat=0.10
-oo vdsm-compat=1.1

Якщо вказано -o vdsm і форматом виведення даних є qcow2, ми додаємо параметр qcow2 compat=0.10 до файла виведених даних для сумісності із RHEL 6 (див. https://bugzilla.redhat.com/1145582).

Якщо використовується -oo vdsm-compat=1.1, замість цього буде створено сучасні файли qcow2 (compat=1.1).

У поточній версії типовим є параметр -oo vdsm-compat=0.10, але його буде змінено на -oo vdsm-compat=1.1 у майбутніх версіях virt-v2v (коли ми зможемо припускати, що усі користуються сучасною версією qemu).

Зауважте, що цей параметр стосується лише даних, виведених при використанні -o vdsm. В усіх інших режимах виведення (зокрема, при використанні -o rhv) завжди створюватимуться файли сучасної версії qcow2, compat=1.1.

Якщо доступний цей параметр, "vdsm-compat-option" буде представлено у форматі виведення --machine-readable.

-oo vdsm-image-uuid=UUID
-oo vdsm-vol-uuid=UUID
-oo vdsm-vm-uuid=UUID
-oo vdsm-ovf-output=КАТАЛОГ

Зазвичай, при використанні режиму виведення RHV програма вибирає псевдовипадкові значення UUID для гостьової системи призначення. Втім, VDSM потребує керування UUID і передає значення цих параметрів, якщо virt-v2v працює під керуванням VDSM. Параметри керують такими значеннями:

Формат запису UUID: "12345678-1234-1234-1234-123456789abc" (кожна шістнадцяткова цифра може приймати значення "0-9" або "a-f"), відповідно до OSF DCE 1.1.

Ці параметри можна використовувати лише з -o vdsm.

-oo vdsm-ovf-flavour=варіант

Цей параметр визначає формат OVF, який буде використано наприкінці перетворення. У поточній версії передбачено два можливих варіанти:
rhvexp

Формат OVF, який використовується у домені експортування RHV.

ovirt

Обробка формату OVF здійснюється за допомогою програмного інтерфейсу REST oVirt.

Для забезпечення зворотної сумісності типовим значенням є rhvexp, але його може бути змінено у майбутньому.

-op файл

Надає файл, який містить пароль і яким слід скористатися для з’єднання із рушієм гіпервізора призначення. Зауважте, що файл має містити увесь пароль, без завершального символу нового рядка, і, з міркувань безпеки, для файла має бути встановлено режим доступу 0600, щоб інші користувачі не змогли його читати.

-os сховище

Розташування сховища даних для перетвореної гостьової системи.

Для -o libvirt цей параметр визначає каталог буфера libvirt (див. "virsh pool-list") або UUID буфера.

For -o local and -o qemu, this is a directory name. The directory must exist.

Для -o rhv-upload це назва домену сховища призначення.

Для -o openstack є необов’язковий тип тому Cinder.

Для -o rhv це може бути шлях NFS домену сховища експортування (Export Storage Domain) у форматі "<вузол>:<шлях>". Приклад:

rhv-storage.example.com:/rhv/export

Місце експортування NFS має бути придатним до монтування та доступним для запису користувачем та вузлом, де запущено virt-v2v, оскільки програмі virt-v2v потрібно буде його змонтувати під час роботи. Отже, ймовірно, вам доведеться запустити virt-v2v від імені користувача "root".

Альтернативний варіант: ви можете змонтувати домен сховища експортування власноруч і вказати його точку монтування за допомогою -os. Зауважте, що virt-v2v все ще потрібно буде вести запис до цього віддаленого каталогу, тому virt-v2v все одно доведеться запускати від імені "root".

Вам буде повідомлено про помилку, якщо virt-v2v не вдасться змонтувати домен сховища експортування або здійснити до нього запис.

--print-source

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

--qemu-boot

This is the same as -oo qemu-boot.

--quiet

Цей параметр вимикає смужки поступу та інші необов’язкові до виведення дані.

--root ask
--root single
--root first
--root /dev/sdX
--root /dev/VG/LV

Вибрати кореневу файлову систему для перетворення.

Якщо у віртуальній машині передбачено декілька варіантів завантаження або у віртуальній машині є сторонні файлові системи, які виглядають як розділи операційних систем, за допомогою цього параметра можна вибрати кореневу файлову систему (тобто диск "C:" або /) операційної системи, яку слід перетворити. Використання консолі відновлення Windows, деякі долучені диски DVD та вади у евристиці засобу інспектування libguestfs можуть призвести до помилкового визначення гостьової операційної системи як такої, у якій передбачено варіанти завантаження.

Типовим варіантом у virt-v2v ≤ 0.7.1 був параметр --root single, який спричиняв аварійне завершення virt-v2v, якщо виявлялася операційна система із варіантами завантаження.

Починаючи з версії virt-v2v ≥ 0.7.2 типовим режимом є --root ask: якщо буде виявлено варіанти завантаження у віртуальній машині, virt-v2v припинить роботу, виведе список усіх можливих кореневих файлових системи і попросить користувача вказати ту, яку слід перетворити. Це потребує роботи virt-v2v у інтерактивному режимі.

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

Ви також можете вказати певний кореневий пристрій за назвою, наприклад, --root /dev/sda2 означає, що слід використати другий розділ на першому диску. Якщо іменованого кореневого пристрою не існує або його не вдасться визначити як кореневий пристрій, virt-v2v повідомить про помилку і завершить роботу.

Зауважте, що у grub є вада, яка заважає успішно завантажувати систему із варіантами завантаження, якщо увімкнено virtio. Grub може завантажувати лише операційні системи з першого диска virtio. Зокрема, /boot має бути першим диском virtio, і grub не може ланцюгово завантажувати операційну систему, яка не зберігається на першому диску virtio.

--verbose

Увімкнути докладний показ повідомлень з метою діагностики.

--version

Показати дані щодо версії і завершити роботу.

--wrap

Wrap error, warning, and informative messages. This is the default when the output is a tty. If the output of the program is redirected to a file, wrapping is disabled unless you use this option.

ПРИМІТКИ

Паравіртуалізовані гостьові системи Xen
У застарілих версіях virt-v2v можна було перетворити паравіртуалізовану гостьову систему Xen на гостьову систему KVM встановленням нового ядра. Ця версія virt-v2v не намагатиметься встановити будь-яке нове ядро. Замість цього, вона повідомить вам про помилку, якщо доступними виявляться лише паравіртуалізовані ядра Xen.

Тому, перш ніж виконувати перетворення, вам слід перевірити, чи встановлено у системі звичайне ядро. Для деяких застарілих дистрибутивів Linux це означає, що має бути встановлено ядро із наведеної нижче таблиці:

RHEL 3 (Неможливо визначити, не було ядра PV Xen)
RHEL 4 i686 з > 10 ГБ пам'яті: встановіть «kernel-hugemem»
i686 SMP: встановіть «kernel-smp»
інші i686: встановіть «kernel»
x86-64 SMP з > 8 процесорів: встановіть «kernel-largesmp»
x86-64 SMP: встановіть «kernel-smp»
інші x86-64: встановіть «kernel»
RHEL 5 i686: встановіть «kernel-PAE»
x86-64: встановіть «kernel»
SLES 10 i586 з > 10 ГБ оперативної пам'яті: встановіть «kernel-bigsmp»
i586 SMP: встановіть «kernel-smp»
інша i586: встановіть «kernel-default»
x86-64 SMP: встановіть «kernel-smp»
other x86-64: встановіть «kernel-default»
SLES 11+ i586: встановіть «kernel-pae»
x86-64: встановіть «kernel-default»
Windows (Неможливо визначити, не існує ядер Windows для PV Xen)

Вмикання virtio
«Virtio» — назва набору драйверів, які значно пришвидшують роботу диска (блокового пристрою), мережі та інших дій у гостьовій системі у KVM.

У застарілих версіях virt-v2v можна було встановити ці драйвери для певних гостьових систем Linux. Ця версія virt-v2v не намагатиметься встановити нові ядра Linux або драйвери, але попередить вас, якщо їх ще не встановлено.

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

RHEL 3 Немає доступних драйверів virtio
RHEL 4 ядро >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
device-mapper >= 1.02.28-2.el4
selinux-policy-targeted >= 1.17.30-2.152.el4
policycoreutils >= 1.18.1-4.13
RHEL 5 ядро >= 2.6.18-128.el5
lvm2 >= 2.02.40-6.el5
selinux-policy-targeted >= 2.4.6-203.el5
RHEL 6+ усі версії підтримують virtio
Fedora усі версії підтримують virtio
SLES 11+ усі версії підтримують virtio
SLES 10 ядро >= 2.6.16.60-0.85.1
OpenSUSE 11+ усі версії підтримують virtio
OpenSUSE 10 ядро >= 2.6.25.5-1.1
Debian 6+ Підтримку virtio передбачено в усіх версіях
Ubuntu 10.04+ — підтримку virtio передбачено в усіх версіях
Windows Drivers are installed from the ISO or directory pointed
to by the "VIRTIO_WIN" environment variable if present.
If the "VIRTIO_WIN" environment variable is absent
(which is the recommended setting), then libosinfo is
consulted first, for driver files that are locally
available on the conversion host.

RHEL 4: Здається, що повторне встановлення міток SELinux «зависло»
У RHEL ≤ 4.7 була вада, яка спричиняла до того, що повторне встановлення міток SELinux «зависало» на такому повідомленні:

*** Warning -- SELinux relabel is required. ***
*** Disabling security enforcement. ***
*** Relabeling could take a very long time, ***
*** depending on file system size. ***

Насправді, система очікувала від вас натискання клавіші (але ніяк візуально про це не повідомляла). Ви можете або натиснути клавішу "[Return]", у результаті чого гостьова система завершить повторне встановлення міток і перезавантажиться, або можете встановити policycoreutils ≥ 1.18.1-4.13 до запуску перетворення v2v. Див. також https://bugzilla.redhat.com/show_bug.cgi?id=244636

Debian і Ubuntu
"попередження: не вдалося визначити спосіб оновлення налаштувань Grub2"

У поточній версії virt-v2v не передбачено способу визначити типове ядро у гостьових системах Debian та Ubuntu, які використовують завантажувач GRUB 2. Це означає, що virt-v2v не змінюватиме типового ядра для завантаження, навіть якщо це не краще ядро, яке доступне у гостьовій системі. Рекомендуємо, перш ніж користуватися virt-v2v, зробити так, щоб типове ядро для завантаження було найкращим з доступних у гостьовій системі ядер (наприклад, просто оновивши гостьову систему до найсвіжішої версії).

"vsyscall attempted with vsyscall=none"

Якщо програму запущено у нещодавній версії основної системи Debian, virt-v2v може виявитися нездатною до перетворення гостьових систем, які було створено до 2013 року. У діагностичних повідомленнях ви зможете побачити повідомлення щодо аварійного завершення роботи, подібне до такого:

vsyscall attempted with vsyscall=none ip:...
segfault at ...

Причиною є те, що у Debian вилучено підтримку запуску застарілих виконуваних файлів, які використовували застарілу сторінку vsyscall для викликів до ядра.

Обійти цю проблему можна за допомогою такої команди, яку слід віддати до запуску virt-v2v:

export LIBGUESTFS_APPEND="vsyscall=emulate"

Докладніший опис можна знайти тут: https://bugzilla.redhat.com/1592061

Windows
System disk on a Dynamic Disk is not supported

If the Windows system disk (the drive containing "\windows") is located on a Dynamic Disk then it cannot be converted. Data disks — that is, disks which are part of the guest but do not contain parts of the Windows operating system — may be Dynamic Disks.

See https://bugzilla.redhat.com/2140548.

Швидкий запуск у Windows ≥ 8 є несумісним із virt-v2v

Гостьові системи, у яких використовується можливість Windows ≥ 8 «Fast Startup» (або гостьові системи, які було приспано), не можна перетворити за допомогою virt-v2v. Програма повідомлятиме про таку помилку:

virtv2v: помилка: не вдалося змонтувати образ диска для запису. Ймовірно, це
сталося через те, що у гостьовій системі використано Windows Hibernation або
Fast Restart. Вам слід вимкнути ці можливості (у гостьовій системі), щоб
скористатися virt-v2v.

Як і повідомляється, вам слід завантажити гостьову систему і вимкнути можливість швидкого запуску (Панель керування → Живлення → Виберіть дію для кнопки живлення → Змінити параметри, які зараз недоступні → Увімкнути швидкий запуск), потім вимкнути гостьову систему. Після цього ви зможете перетворити її.

Щоб дізнатися більше, див. "ПРИСИПЛЯННЯ WINDOWS ТА ШВИДКИЙ ЗАПУСК WINDOWS 8" in guestfs(3).

Boot failure: 0x0000007B

Неможливість завантаження спричинено тим, що Windows не може знайти або завантажити належний драйвер диска (наприклад viostor.sys). Якщо у вас виникає ця помилка, ось декілька речей, які можуть допомогти:

У Red Hat Enterprise Linux 7 вам слід буде встановити підписані драйвери з пакунка "virtio-win". Якщо у вас немає доступу до підписаних драйверів, вам, ймовірно, слід вимкнути підписування драйверів у меню завантаження.

... -drive file=windows-sda,if=virtio ...

У XML libvirt має бути таке:

<target dev='vda' bus='virtio'/>

OpenStack і повторна активація Windows

OpenStack не надає гостьовим системам стабільних адрес пристроїв та каналів PCI. Кожного разу, коли створюється або запускається гостьова система, OpenStack повторно створює від початку XML libvirt для цієї гостьової системи. Створений таким чином XML libvirt не міститиме полів <address>. Потім libvirt призначить адреси для пристроїв у передбачуваний спосіб. Адреси можуть змінитися, якщо буде виконано будь-яку з таких умов:

Оскільки Windows не подобаються такі «апаратні» зміни, це може спровокувати початок процедури повторної активації Windows.

Це також може заважати завантаженню із повідомленням про помилку 7B [див. попередній розділ], якщо у гостьовій системі є group policy із назвою "Device Installation Restrictions".

Підтримка сертифікатів SHA-2 у Windows 7 та Windows Server 2008 R2

Нещодавні версії драйверів vitio для Windows підписано за допомогою сертифікатів SHA-2 (замість сертифікатів SHA-1). Початкові версії Windows 7 і Windows Server 2008 R2 не здатні працювати із сертифікатами SHA-2, тому драйвери virtio для Windows у цих системах не може бути встановлено належним чином.

Щоб усунути цю проблему, перш ніж виконувати перетворення гостьової системи, вам слід встановити у системах підтримку підписування коду SHA-2: https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3033929.

Докладніші дані можна знайти на сторінці https://bugzilla.redhat.com/show_bug.cgi?id=1624878

Мережі і містки
Гостьові системи, зазвичай, з’єднано із однією або декількома мережами, і при перетворенні до гіпервізору призначення вам, зазвичай, потрібно повторно з’єднати ці мережі на вузлі призначення. Зробити це можна за допомогою параметрів --network, --bridge та --mac.

Якщо ви не певні щодо того, які мережі і містки використовуються у початковому гіпервізорі, ви можете вивчити початкові метадані (XML libvirt, дані vCenter тощо). Ви також можете запустити virt-v2v з параметром --print-source, який призведе до того, що virt-v2v виведе доступну програмі інформацію щодо початкового варіанта гостьової системи, а потім завершить роботу.

У виведених даних з параметром --print-source ви побачите розділ, де буде показано картки мережевих інтерфейсів (NIC) гостьової системи:

$ virt-v2v [-i ...] --print-source name
[...]
NIC:
Network "default" mac: 52:54:00:d0:cf:0e

Містки є особливим класом пристроїв мережі, які долучаються до іменованої зовнішньої мережі на гіпервізорі джерела. Приклад:

$ virt-v2v [-i ...] --print-source name
[...]
NICs:
Bridge "br0"

Щоб пов’язати певний місток-джерело до мережі призначення, наприклад, місток "br0" у початковій системі із мережею "ovirtmgmt" у системі призначення, скористайтеся такою командою:

virt-v2v [...] --bridge br0:ovirtmgmt

Щоб пов’язати усі містки із мережею призначення, скористайтеся такою командою:

virt-v2v [...] --bridge ovirtmgmt

Тонкощі прив’язки гостьових NIC

Параметр --mac надає вам ширші можливості керування прив’язкою, надаючи змогу прив’язувати окремі NIC до мереж або містків у системі призначення. Наприклад, у початковій гостьовій системі із двома NIC їх можна пов’язати окремо із двома мережами із назвами "mgmt" та "clientdata" ось так:

$ virt-v2v [...] \
--mac 52:54:00:d0:cf:0e:network:mgmt \
--mac 52:54:00:d0:cf:0f:network:clientdata

Зауважте, що у virt-v2v не передбачено можливостей зміни MAC-адреси гостьової системи. MAC-адреса є частиною метаданих гостьової системи і має лишатися тією самою у гіпервізорі походження та у гіпервізорі призначення. У більшості гостьових систем MAC-адреса використовується для встановлення сталих зв’язків між NIC та внутрішніми назвами (наприклад "eth0"), зв’язків із параметрами брандмауера або навіть зв’язків із системами ліцензування програмного забезпечення.

Вимоги щодо ресурсів
Мережа

Здається, найважливішим ресурсом для virt-v2v є канал мережі. Virt-v2v повинна мати можливість копіювати дані гостьових систем із гігабітними або навіть вищими швидкостями мережею.

Вам слід забезпечити швидке і якомога менш латентне з’єднання між серверами (сервером перетворення, сервером NFS, vCenter, Xen).

Місце на диску

Virt-v2v places potentially large temporary files in $VIRT_V2V_TMPDIR (usually /var/tmp, see also "ENVIRONMENT VARIBLES" below). Using tmpfs is a bad idea.

Для кожного диска гостьової системи тимчасово зберігається накладка. У ній містяться дані щодо змін, які було внесено з часу перетворення, а також дані кешу. Накладки не є дуже великими — типово десятки або декілька сотень мегабайтів. Окрім накладок, місце на диску може використовуватися засобами обробки вхідних і вихідних даних. Дані щодо цих витрат місця на диску наведено у викладеній нижче таблиці.
-i ova

This temporarily places a full copy of the uncompressed source disks in $VIRT_V2V_TMPDIR (or /var/tmp).

-o glance

This temporarily places a full copy of the output disks in $VIRT_V2V_TMPDIR (or /var/tmp).

-o local
-o qemu

Вам слід переконатися щодо у каталозі для виведення даних є достатньо вільного місця для перетвореної гостьової системи.

Див. також "Мінімальне вільне місце у основній системі" нижче.

Ресурси vCenter VMware

У поточній версії копіювання з vCenter VMware є дуже повільним, ми вважаємо, що це проблема з VMware. Щоб частково усунути цю проблему, слід забезпечити роботу гіпервізору ESXi VMware та vCenter на швидкому обладнанні із великим обсягом пам’яті.

Обчислювальні потужності і обсяг оперативної пам’яті

Virt-v2v не є особливо вимогливою до обчислювальних можливостей або обсягу пам’яті. Якщо ви виконуєте багато паралельних перетворень, вам варто виділити одне ядро процесора і 2 ГБ оперативної пам’яті на кожен запущений екземпляр.

Virt-v2v можна запускати у віртуальній машині.

Обрізання

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

Для виконання цього завдання virt-v2v використовує неруйнівну дію fstrim(8). Оскільки відповідна програма виконує дії із накладкою над даними гостьової системи, початкова система ніяким чином не змінюється.

Якщо робота цієї програми fstrim завершується помилкою, ви побачите попередження, а virt-v2v продовжить роботу. Програма може працювати повільніше (у деяких випадках набагато повільніше) через те, що копіюватиме і невикористані частини диска.

На жаль, підтримка fstrim не є універсальною. Результат також залежить від певних параметрів файлової системи, вирівнювання розділів та резервного сховища даних. Наприклад, fstrim не можна застосовувати до файлових систем NTFS, якщо вони займають розділи, які не вирівняно із базових сховищем даних. Такого вирівнювання типово не було у Windows до Vista. Іншим прикладом є файлові системи VFAT (використовуються гостьовими системами UEFI) — їх взагалі не можна обрізати.

Підтримка fstrim у ядрі Linux поступово поліпшується, отже, з часом, ці обмеження буде знято і virt-v2v працюватиме швидше.

Завдання після перетворення
Налаштовування гостьової мережі

У поточній версії virt-v2v не може переналаштувати мережу у гостьовій системі. Якщо перетворену гостьову систему не з’єднано із тією самою підмережею, що і початкову, її налаштування мережі має бути оновлено. Див. також virt-customize(1).

Перетворення гостьової системи Windows

Процес перетворення гостьових систем Windows поділено на два етапи:

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

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

Вільне місце для перетворення
Вільне місце у гостьовій системі

Virt-v2v перевіряє, чи достатньо місця у гостьовій файловій системі для виконання перетворення. У поточній версії програма перевіряє таке:
Linux root filesystem

Minimum free space: 100 MB

Linux /boot

Мінімальний вільний простір: 50 МБ

Причиною є те, що нам потрібно збирати нові initramfs для деяких перетворень Enterprise Linux.

Windows "C:" drive

Minimum free space: 100 MB

We may have to copy in many virtio drivers and guest agents.

Будь-яка інша придатна до монтування файлова система

Мінімальний вільний простір: 10 МБ

Окрім самого вільного місця на диску, для кожної файлової системи потрібно принаймні 100 вільних записів inode.

Мінімальний обсяг місця у основній системі

You must have sufficient free space in the host directory used to store large temporary overlays. To find out which directory this is, use:

$ df -h "`guestfish get-cachedir`"
Ф. система Розм Вик Дост Вик% змонтований на
/dev/mapper/root 50G 40G 6.8G 86% /

and look under the "Avail" column. Virt-v2v will refuse to do the conversion at all unless at least 1GB is available there. You can change the directory that virt-v2v uses by setting $VIRT_V2V_TMPDIR.

See also "Resource requirements" above and "ENVIRONMENT VARIABLES" below.

Запуск virt-v2v від імені root чи не від імені root
Нічого у virt-v2v не потребує обов’язкових прав доступу root — програма чудово працює і від імені звичайного користувача. Втім, використання деяких зовнішніх можливостей може потребувати прав доступу root або інших спеціалізованих користувачів:
Монтування Export Storage Domain

При використанні параметрів -o rhv -os server:/esd virt-v2v повинна мати достатні права доступу до змонтованої системи NFS домену сховища експортування з сервера "server".

Ви можете уникнути тут потреби у використання прав доступу root, якщо змонтуєте диск власноруч до запуску virt-v2v і передасте його як параметр команди -os /точка_монтування, але перед цим прочитайте наступний розділ...

Запис до Export Storage Domain від імені 36:36

RHV-M не зможе прочитати файли і каталоги з Export Storage Domain, якщо їхнім власником не буде UID:GID 36:36. Якщо значення UID:GID виставлено неправильно, ви побачите повідомлення про проблеми з імпортуванням даних з віртуальної машини.

Коли ви запускаєте virt-v2v -o rhv від імені користувача root, virt-v2v намагатиметься створити файли і каталоги із правильними записами власників. Якщо ж virt-v2v запускатиметься від імені непривілейованого користувача, програма, ймовірно, працюватиме, але вам доведеться вручну змінити права власності на файли і каталоги після завершення роботи virt-v2v.

Запис до libvirt

Якщо використовується параметр -o libvirt, може виникнути потреба у запуску virt-v2v від імені користувача root для уможливлення запису до каталогу загальносистемного екземпляра libvirt (тобто до "qemu:///system";) і до типового каталогу для образів дисків (зазвичай, /var/lib/libvirt/images).

Ви можете уникнути цього, налаштувавши розпізнавання у з’єднанні із libvirt, див. http://libvirt.org/auth.html. Крім того, можна скористатися параметром -oc qemu:///session, використання якого призведе до запису даних до каталогів libvirt вашого користувача.

See also "Starting the libvirt system instance".

Запис до Openstack

Через спосіб, у який томи Cinder представляються як блокові пристрої /dev, використання -o openstack зазвичай потребує запуску virt-v2v від імені користувача root.

Запис до Glance

Ця дія не потребує прав доступу root (фактично, вона, ймовірно, не працюватиме з ними), але може потребувати прав доступу спеціалізованого користувача і/або створення скрипту для встановлення змінних середовища, пов’язаних із розпізнаванням користувача. Зверніться до документації із Glance.

Writing to block devices

This normally requires root. See the next section.

Writing to block devices
Some output modes write to local files. In general these modes also let you write to block devices, but before you run virt-v2v you may have to arrange for symbolic links to the desired block devices in the output directory.

For example if using -o local -os /dir then virt-v2v would normally create files called:

/dir/name-sda # first disk
/dir/name-sdb # second disk
...
/dir/name.xml # metadata

If you wish the disks to be written to block devices then you would need to create /dir/name-sda (etc) as symlinks to the block devices:

# lvcreate -L 10G -n VolumeForDiskA VG
# lvcreate -L 6G -n VolumeForDiskB VG
# ln -sf /dev/VG/VolumeForDiskA /dir/name-sda
# ln -sf /dev/VG/VolumeForDiskB /dir/name-sdb

Note that you must precreate the correct number of block devices of the correct size. Typically -of raw has to be used too, but other formats such as qcow2 can be useful occasionally so virt-v2v does not force you to use raw on block devices.

Мінімальний XML для параметра -i libvirtxml
Якщо використовується параметр -i libvirtxml, вам слід буде вказати певний файл XML libvirt. Написання такого файла «з нуля» є доволі марудною справою, отже, вам буде корисний наведений нижче шаблон.

Зауважте, що цим слід користуватися лише для тестування і/або там, де ви впевнені у своїх діях! Якщо у вас є метадані libvirt для гостьової системи, завжди користуйтеся ними, а не цим шаблоном.

<domain type='kvm'>
<name> NAME </name>
<memory>1048576</memory>
<vcpu>2</vcpu>
<os>
<type>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<devices>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/path/to/disk/image'/>
<target dev='hda' bus='ide'/>
</disk>
<interface type='network'>
<mac address='52:54:00:01:02:03'/>
<source network='default'/>
<model type='rtl8139'/>
</interface>
</devices>
</domain>

Придатне до читання компʼютером виведення
Для виведення даних у зручному для машинної обробки форматі можна скористатися параметром --machine-readable. Додавання цього параметра робить зручним використання virt-v2v з інших програм, графічних інтерфейсів тощо.

Існує два способи використання цього параметра.

Спочатку, скористайтеся цим параметром окремо, щоб опитати систему щодо можливостей виконуваного файла virt-v2v. Типово виведені дані виглядатимуть якось так:

$ virt-v2v --machine-readable
virt-v2v
libguestfs-rewrite
colours-option
vdsm-compat-option
input:disk
[...]
output:local
[...]
convert:linux
convert:windows

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

Записи "input:" і "output:" стосуються аргументів параметрів -i і -o (вхідного і вихідного режимів), які підтримуються цим виконуваним файлом. Записи "convert:" стосуються типів гостьових систем, підтримку перетворення яких передбачено у цьому виконуваному файлі.

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

У поточній версії це означає таке:

^[0-9]+/[0-9]+$

У virt-v2v ≤ 0.9.1 взагалі не передбачено підтримки параметра --machine-readable. Цей параметр було додано під час переписування virt-v2v у 2014 році.

Можна вказати рядок форматування для керування виведенням, див. "РОЗШИРЕНЕ ПРИДАТНЕ ДО ЧИТАННЯ КОМП’ЮТЕРОМ ВИВЕДЕННЯ" in guestfs(3).

Starting the libvirt system instance
Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory
Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': Connection refused

If you have just installed libvirt and virt-v2v, then you may see the errors above. This is caused by libvirt daemons that provide various services not running straight after installation. (This may depend on your distribution and vendor presets).

To fix this on systemd-based distributions, do:

systemctl isolate multi-user.target

See also https://bugzilla.redhat.com/2182024.

ФАЙЛИ

/usr/share/virtio-win

(Необов’язково)

Якщо існує цей каталог, драйвери virtio для гостьових систем Windows буде знайдено у цьому каталозі і встановлено до гостьової системи під час перетворення.

ЗМІННІ СЕРЕДОВИЩА

"VIRT_V2V_TMPDIR"
"LIBGUESTFS_CACHEDIR"

Location of the temporary directory used for the potentially large temporary overlay file. If neither environment variable is set then /var/tmp is used.

To reliably ensure large temporary files are cleaned up (for example in case virt-v2v crashes) you should create a randomly named directory under /var/tmp, set "VIRT_V2V_TMPDIR" to point to this directory, then when virt-v2v exits remove the directory.

Див. розділ "Місце на диску" вище.

"VIRT_TOOLS_DATA_DIR"

Ця змінна визначає каталог, у якому містяться файли даних, які використовуються для перетворення Windows.

Зазвичай, потреби у встановленні власного значення немає. Якщо значення не встановлено, буде використано вбудоване типове значення (щось схоже на /usr/share/virt-tools).

Цей каталог може містити такі файли:
rhsrvany.exe

(Потрібен для перетворень гостьових систем Windows)

Це виконуваний файл для Windows RHSrvAny, який використовується для встановлення скрипту «firstboot» у гостьові системи під час перетворення гостьових систем Windows.

Див. також "https://github.com/rwmjones/rhsrvany";

pnp_wait.exe

(Recommended when doing conversions of Windows guests)

This tool waits for newly installed Windows devices to become available before trying to configure them, for example to set network configuration. It is part of the RHSrvAny project.

pvvxsvc.exe

This is a Windows binary shipped with SUSE VMDP, used to install a "firstboot" script in Windows guests. It is an alternative to RHSrvAny.

"VIRTIO_WIN"

This is an override for where virtio drivers for Windows are searched for. It can be a directory or point to virtio-win.iso (CD ROM image containing drivers).

If unset, then we look for drivers via whichever of these methods succeeds first:
"osinfo-db"

Load osinfo data from the default paths, and attempt to find drivers via libosinfo lookup. This is the preferred method.

/usr/share/virtio-win/virtio-win.iso

Образ ISO, де містяться драйвери virtio для Windows.

/usr/share/virtio-win

The exploded tree of virtio drivers for Windows. This is usually incomplete, hence the least preferred method.

Див. "Вмикання virtio".

Опис інших змінних середовища наведено у розділі "ENVIRONMENT VARIABLES" in guestfs(3).

ІНШІ ІНСТРУМЕНТИ

engine-image-uploader(8)

Цей інструмент може називатися "engine-image-uploader", "ovirt-image-uploader" або "rhevm-image-uploader". За його допомогою можна скопіювати гостьову систему з одного домену сховища експортування oVirt або RHV до іншого. Його використання надає змогу імпортувати лише ті гостьові системи, які раніше було експортовано з іншого екземпляра oVirt/RHV.

import-to-ovirt.pl

Цим скриптом можна скористатися для імпортування гостьових систем, які вже запущено у KVM до oVirt або RHV. Щоб дізнатися більше, ознайомтеся із цим дописом у блозі автора virt-v2v:

https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/#content

ТАКОЖ ПЕРЕГЛЯНЬТЕ

virt-p2v(1), virt-v2v-inspector(1), virt-v2v-in-place(1), virt-customize(1), virt-df(1), virt-filesystems(1), virt-sparsify(1), virt-sysprep(1), guestfs(3), guestfish(1), qemu-img(1), engine-image-uploader(8), import-to-ovirt.pl, nbdkit(1), nbdkit-vddk-plugin(1), http://libguestfs.org/.

АВТОРИ

Matthew Booth

Cédric Bosdonnat

Laszlo Ersek

Tomáš Golembiovský

Shahar Havivi

Richard W.M. Jones

Roman Kagan

Mike Latimer

Nir Soffer

Pino Toscano

Xiaodai Wang

Ming Xie

Tingting Zheng

АВТОРСЬКІ ПРАВА

Copyright (C) 2009-2022 Red Hat Inc.

LICENSE

BUGS

To get a list of bugs against libguestfs, use this link: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools

To report a new bug against libguestfs, use this link: https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools

When reporting a bug, please supply: