Розпізнавання за допомогою SSH¶

Ви можете скористатися розпізнаванням за допомогою SSH за паролем, вказавши назву файла, який містить пароль, як аргумент параметра -ip (зауважте, що цей параметр не приймає пароль безпосередньо). Вам слід скоригувати /etc/ssh/sshd_config на сервері Xen, встановивши "PasswordAuthentication yes".

Якщо ви не використовуєте розпізнавання за паролем, альтернативою є використання ssh-agent і додавання вашого відкритого ключа ssh до /root/.ssh/authorized_keys (у основній системі Xen). Після виконання цих дій вам слід перевірити, чи працює доступ без пароля з сервера virt-v2v до основної системи Xen. Приклад:

 $ ssh root@xen.example.com
 [ журналювання безпосередньо до оболонки, пароль не потрібен ]

Зауважте, що підтримка неінтерактивного розпізнавання за допомогою параметра -ip є неповною. Деякі дії все ще вимагають від користувача введення пароля вручну. Тому рекомендуємо скористатися ssh-agent замість параметра -ip. Див. https://bugzilla.redhat.com/1854275.

У деяких сучасних реалізаціях ssh застарілі алгоритми шифрування, потрібні для взаємодії із sshd RHEL 5 вимкнено. Щоб увімкнути ці алгоритми, вам, можливо, слід додати таку інструкцію "Host" до вашого ~/.ssh/config:

 Host xen.example.com
   KexAlgorithms            +diffie-hellman-group14-sha1
   MACs                     +hmac-sha1
   HostKeyAlgorithms        +ssh-rsa
   PubkeyAcceptedKeyTypes   +ssh-rsa
   PubkeyAcceptedAlgorithms +ssh-rsa

("PubkeyAcceptedKeyTypes" і "PubkeyAcceptedAlgorithms" означають те саме; перша назва є назвою застарілого параметра, друга — нового. Virt-v2v використовує "libssh" і "ssh" при перетворенні з Xen, і у деяких операційних системах "libssh" і "ssh" можуть одразу приймати той самий варіант параметра.)

При встановленні з'єднання з sshd RHEL 5 з RHEL 9, використання алгоритму SHA1 у підписах має бути повторно увімкнено на рівні OpenSSL на додачу до наведених вище налаштувань SSH. Створіть файл з назвою $HOME/openssl-sha1.cnf і таким вмістом:

 .include /etc/ssl/openssl.cnf
 [openssl_init]
 alg_section = evp_properties
 [evp_properties]
 rh-allow-sha1-signatures = yes

і експортуйте таку змінну до середовища процесу "virt-v2v":

 OPENSSL_CONF=$HOME/openssl-sha1.cnf

Зауважте, що змінна середовища "OPENSSL_CONF" працюватиме лише тоді, коли а клієнтська бібліотека libvirt, використана virt-v2v, має версію принаймні 8.6.0.

Перевірка з'єднання libvirt із віддаленою основною системою Xen¶

Скористайтеся командою virsh(1) для отримання списку гостьових систем на віддаленому вузлі Xen:

 $ virsh -c xen+ssh://root@xen.example.com list --all
  Id    Name                           State
 ----------------------------------------------------
  0     Domain-0                       running
  -     rhel49-x86_64-pv               shut off

Крім того, вам слід спробувати створити дамп метаданих з будь-якої гостьової системи на вашому сервері, ось так:

 $ virsh -c xen+ssh://root@xen.example.com dumpxml rhel49-x86_64-pv
 <domain type='xen'>
   <name>rhel49-x86_64-pv</name>
   [...]
 </domain>

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

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

Імпортування гостьової системи¶

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

 $ virt-v2v -ic 'xen+ssh://root@xen.example.com' \
           rhel49-x86_64-pv \
           -o local -os /var/tmp

де "rhel49-x86_64-pv" — назва гостьової системи (яку має бути вимкнено).

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

Перетворення Xen або ssh з блокових пристроїв¶

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

Щоб визначити, чи використовує гостьова система Xen блокові пристрої основної системи, зверніться до вмісту XML гостьової системи. Там ви побачите таке:

  <disk type='block' device='disk'>
    ...
    <source dev='/dev/VG/guest'/>

де "type='block'", "source dev=" і "/dev/..." усі вказують на тек, що диск розташовано на блоковому пристрої основної системи.

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

Обійти цю проблему можна копіюванням блокового пристрою з віддаленого сервера Xen до звичайного локального файла, копіюванням XML гостьової системи libvirt, коригуванням елемента "disk" так, щоб він вказував на локальний файл і заміною режиму на "-i libvirtxml".