Input and Output¶

You normally run virt-v2v with several -i* options controlling the input mode and also several -o* options controlling the output mode. In this sense, "input" refers to the source foreign hypervisor such as VMware, and "output" refers to the target KVM-based management system such as oVirt or OpenStack.

The input and output sides of virt-v2v are separate and unrelated. Virt-v2v can read from any input and write to any output. Therefore these sides of virt-v2v are documented separately in this manual.

Virt-v2v normally copies from the input to the output, called "copying mode". In this case the source guest is always left unchanged. In-place conversion (--in-place) only uses the -i* options and modifies the source guest in-place. (See "In-place conversion" below.)

Other virt-v2v topics¶

virt-v2v-support(1) — Supported hypervisors, virtualization management systems, guests.

virt-v2v-input-vmware(1) — Input from VMware.

virt-v2v-input-xen(1) — Input from Xen.

virt-v2v-output-local(1) — Output to local files or local libvirt.

virt-v2v-output-rhv(1) — Output to oVirt or RHV.

virt-v2v-output-openstack(1) — Output to OpenStack.

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

virt-v2v-copy-to-local(1) — Deprecated tool to handle Xen guests using host block device storage.

Перетворення з сервера 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.

For more information see virt-v2v-input-vmware(1).

Перетворення з VMware до RHV/oVirt¶

This is the same as the previous example, except you want to send the guest to a RHV Data Domain using the RHV REST API. Guest network interface(s) are connected to the target network called "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 -oo rhv-direct \
   --bridge ovirtmgmt

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

For more information see virt-v2v-output-rhv(1).

Перетворення з гіпервізору ESXi за допомогою SSH до локальної libvirt¶

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

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

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

For more information about converting from VMX files see virt-v2v-input-vmware(1).

Convert disk image to OpenStack¶

Given a disk image from another hypervisor that you want to convert to run on OpenStack (only KVM-based OpenStack is supported), you can run virt-v2v inside an OpenStack VM (called "v2v-vm" below), and do:

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

See 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 --qemu-boot

Xen paravirtualized guests¶

У застарілих версіях 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)

Enabling 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        драйвери встановлюються з ISO або каталогу, на який
                вказує змінна середовища VIRTIO_WIN, якщо її встановлено

RHEL 4: SELinux relabel appears to hang forever¶

У 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"

When run on a recent Debian host virt-v2v may fail to convert guests which were created before 2013. In the debugging output you will see a crash message similar to:

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

This is caused because Debian removed support for running old binaries which used the legacy vsyscall page to call into the kernel.

You can work around this problem by running this command before running virt-v2v:

 export LIBGUESTFS_APPEND="vsyscall=emulate"

For more information, see https://bugzilla.redhat.com/1592061

Windows¶

Швидкий запуск у 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). Якщо у вас виникає ця помилка, ось декілька речей, які можуть допомогти:

• Спочатку, до перетворення, переконайтеся, що гостьова система завантажується на початковому гіпервізорі.
• Перевірте, чи є у вас драйвери virtio Windows у /usr/share/virtio-win, і що virt-v2v не виводила жодних попереджень щодо неможливості встановити драйвери virtio.

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

• Перевірте, чи ви надаєте інтерфейс virtio-blk (не virtio-scsi і не ide) гостьовій системі. У командному рядку qemu/KVM ви маєте бачити щось подібне до такого:

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

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

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

• Перевірте, чи не запобігає Windows Group Policy встановленню або використанню драйвера. Спробуйте вилучити Windows Group Policy до перетворення.
• Перевірте, чи не встановлено якогось антивірусного або іншого програмного забезпечення, яке реалізує заборони, подібні до Group Policy, щодо встановлення або використання нових драйверів.
• Увімкніть діагностику завантаження і перевірте, чи завантажується драйвер viostor.sys.

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

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

• До гостьової системи було додано новий диск або мережевий пристрій або з гостьової системи було вилучено диск або мережевий пристрій.
• Було змінено версію OpenStack або (можливо) libvirt.

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

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

Support for SHA-2 certificates in Windows 7 and Windows Server 2008 R2

Later versions of the Windows virtio drivers are signed using SHA-2 certificates (instead of SHA-1). The original shipping Windows 7 and Windows Server 2008 R2 did not understand SHA-2 certificates and so the Windows virtio drivers will not install properly.

To fix this you must apply SHA-2 Code Signing Support from: https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3033929 before converting the guest.

For further information see: https://bugzilla.redhat.com/show_bug.cgi?id=1624878

Networks and bridges¶

Guests are usually connected to one or more networks, and when converted to the target hypervisor you usually want to reconnect those networks at the destination. The options --network, --bridge and --mac allow you to do that.

Якщо ви не певні щодо того, які мережі і містки використовуються у початковому гіпервізорі, ви можете вивчити початкові метадані (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

Bridges are special classes of network devices which are attached to a named external network on the source hypervisor, for example:

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

To map a specific source bridge to a target network, for example "br0" on the source to "ovirtmgmt" on the target, use:

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

To map every bridge to a target network, use:

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

Fine-grained mapping of guest NICs

The --mac option gives you more control over the mapping, letting you map single NICs to either networks or bridges on the target. For example a source guest with two NICs could map them individually to two networks called "mgmt" and "clientdata" like this:

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

Note that virt-v2v does not have the ability to change a guest’s MAC address. The MAC address is part of the guest metadata and must remain the same on source and target hypervisors. Most guests will use the MAC address to set up persistent associations between NICs and internal names (like "eth0"), with firewall settings, or even for other purposes like software licensing.

Resource requirements¶

Мережа

Здається, найважливішим ресурсом для 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 працюватиме швидше.

Post-conversion tasks¶

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

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

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

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

1.

Автономне перетворення.

2.

Перше завантаження.

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

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

Free space for conversion¶

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

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 МБ

In addition to the actual free space, each filesystem is required to have at least 100 available inodes.

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

You must have sufficient free space in the host directory used to store large temporary overlays (except in --in-place mode). 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.

Running virt-v2v as root or non-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 вашого користувача.

Writing to Openstack

Because of how Cinder volumes are presented as /dev block devices, using -o openstack normally requires that virt-v2v is run as 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.

Minimal XML for -i libvirtxml option¶

Якщо використовується параметр -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>

In-place conversion¶

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

У цьому випадку припускається, що віртуальну машину призначення створено стороннім інструментом у підтримуваному гіпервізорі на основі KVM з використанням налаштувань і вмісту початкової віртуальної машини, але з використанням віртуальних пристроїв, які краще пристосовано до KVM (наприклад, сховища і мережі virtio тощо).

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

 virt-v2v -ic qemu:///system converted_vm --in-place

Virt-v2v проаналізує налаштування перетвореної віртуальної машини "converted_vm" у екземплярі libvirt "qemu:///system" і застосує різноманітні виправлення у налаштуваннях гостьової операційної системи, щоб зробити їх відповідними до налаштувань віртуальної машини. Це може включати встановлення драйверів virtio, налаштовування завантажувача, точок монтування, інтерфейсів мережі тощо.

Якщо під час виконання дії станеться помилка, virt-v2v завершить роботу із кодом помилки, залишивши віртуальну машину у невизначеному стані.

Machine readable output¶

Для виведення даних у зручному для машинної обробки форматі можна скористатися параметром --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:" стосуються типів гостьових систем, підтримку перетворення яких передбачено у цьому виконуваному файлі.

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

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

1.

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

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

2.

Програма, яка надсилає виклик, має обробляти повідомлення, надіслані до стандартного виведення, (окрім повідомлень смужки поступу) як повідомлення щодо стану. Ці повідомлення може бути записано до журналу і/або показано користувачеві.

3.

Програма, яка надсилає виклик, має обробляти повідомлення, надіслані до stderr як повідомлення про помилки. Крім того, virt-v2v завершує роботу із ненульовим кодом стану, якщо станеться критична помилка.

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

It is possible to specify a format string for controlling the output; see "ADVANCED MACHINE READABLE OUTPUT" in guestfs(3).