virt-v2v-input-xen —
використання
virt-v2v для
перетворення
гостьових
систем з Xen
virt-v2v -ic 'xen+ssh://[email protected]'
-ip passwordfile
GUEST_NAME [-o* options]
На цій
сторінці
викладено
документацію
щодо
використання
virt-v2v(1) для
перетворення
гостьових
систем з Xen
основних
систем під
керуванням
RHEL 5, SLES та OpenSUSE.
You can use SSH password authentication, by supplying the name of a file
containing the password to the
-ip option (note this option does
not take the password directly). You may need to adjust
/etc/ssh/sshd_config on the Xen server to set
"PasswordAuthentication yes".
Якщо ви не
використовуєте
розпізнавання
за паролем,
альтернативою
є
використання
ssh-agent і
додавання
вашого
відкритого
ключа ssh до
/root/.ssh/authorized_keys (у
основній
системі Xen).
Після
виконання
цих дій вам
слід
перевірити,
чи працює
доступ без
пароля з
сервера virt-v2v
до
основної
системи Xen.
Приклад:
$ ssh [email protected]
[ журналювання безпосередньо до оболонки, пароль не потрібен ]
Note that support for non-interactive authentication via the
-ip option
is incomplete. Some operations remain that still require the user to enter the
password manually. Therefore ssh-agent is recommended over the
-ip
option. See
https://bugzilla.redhat.com/1854275.
With some modern ssh implementations, legacy crypto algorithms required to
interoperate with RHEL 5 sshd are disabled. To enable them, you may need to
add the following "Host" stanza to your
~/.ssh/config:
Host xen.example.com
KexAlgorithms +diffie-hellman-group14-sha1
MACs +hmac-sha1
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
("PubkeyAcceptedKeyTypes" and "PubkeyAcceptedAlgorithms"
have identical meaning; the former is the old option name, the latter is the
new one. Virt-v2v uses both "libssh" and "ssh" when
converting a guest from Xen, and on some operating systems, "libssh"
and "ssh" may not both accept the same option variant.)
When connecting to RHEL 5 sshd from RHEL 9, the SHA1 algorithm's use in
signatures has to be re-enabled at the OpenSSL level, in addition to the above
SSH configuration. Create a file called
$HOME/openssl-sha1.cnf with the following contents:
.include /etc/ssl/openssl.cnf
[openssl_init]
alg_section = evp_properties
[evp_properties]
rh-allow-sha1-signatures = yes
and export the following variable into the environment of the
"virt-v2v" process:
OPENSSL_CONF=$HOME/openssl-sha1.cnf
Note that the "OPENSSL_CONF" environment variable will only take
effect if the libvirt client library used by virt-v2v is at least version
8.6.0.
Скористайтеся
командою
virsh(1) для
отримання
списку
гостьових
систем на
віддаленому
вузлі Xen:
$ virsh -c xen+ssh://[email protected] list --all
Id Name State
----------------------------------------------------
0 Domain-0 running
- rhel49-x86_64-pv shut off
Крім того,
вам слід
спробувати
створити
дамп
метаданих
з будь-якої
гостьової
системи на
вашому
сервері,
ось так:
$ virsh -c xen+ssh://[email protected] 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://[email protected]' \
rhel49-x86_64-pv \
-o local -os /var/tmp
де "rhel49-x86_64-pv" —
назва
гостьової
системи
(яку має
бути
вимкнено).
У цьому
випадку
прапорці
виведення
встановлено
так, щоб
перетворена
гостьова
система
записувалася
до
тимчасового
каталогу,
оскільки
це лише
приклад,
але ви
також
можете
записати
перетворену
систему до
libvirt або
будь-якого
іншого
підтримуваного
призначення.
У поточній
версії 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,
а цей
протокол
не може
правильно
визначати
розмір
блокових
пристроїв
основної
системи.
The workaround is to copy the block device from the remote Xen server to a
regular local file, copy the libvirt guest XML, adjust the "disk"
element to point to the local file, and use "-i libvirtxml" mode
instead.
virt-v2v(1).
Richard W.M. Jones
© Red Hat Inc., 2009–2020
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:
- •
- The version of libguestfs.
- •
- Where you got libguestfs (eg. which Linux distro, compiled
from source, etc)
- •
- Describe the bug accurately and give a way to reproduce
it.
- •
- Run libguestfs-test-tool(1) and paste the
complete, unedited output into the bug report.