[ovirt-devel] virt-v2v intergration with vdsm

[Richard W.M. Jones]

To expand on the previous email, the web page is quite vague about
what precise sources you want to import from.

The ones supported by virt-v2v are:

 - VMware live vCenter: I assume you would want this.  (Note ESXi is
   mentioned in the web page, but virt-v2v does not support import
   from ESXi directly)

 - OVA file: As Shahar wrote this bit, I'll assume you'll want to use
   it.

 - RHEL 5 Xen: SSH key management is going to be a problem here.

 - Local disk files: Seems unlikely you'll want this.

 - Citrix Xen, Hyper-V, etc.: Requires development work.

 - Physical machines

VMware vCenter
--------------

See: http://libguestfs.org/virt-v2v.1.html#input-from-vmware-vcenter-server

The user will need to specify:
 - hostname of VMware vCenter server
 - optional port number
 - username
 - password
 - name of VMware Datacenter
 - hostname of VMware ESXi server [may be able to relax this in future]
 - whether or not to check HTTPS certs
 - name of the guest

As detailed in the link above, there are various virsh commands you
can run from VDSM to establish whether conversion is likely to work,
and to get a list of guests which you can present to the user.

OVA file
--------

The user will need to specify:
 - OVA file (eg. location)

I've no idea how the file will end up being accessible to VDSM.  NFS mount?

RHEL 5 Xen
----------

See: http://libguestfs.org/virt-v2v.1.html#input-from-rhel-5-xen

I think we're going to have a problem with ssh keys, because this mode
currently only works when the virt-v2v client can get passwordless
access to the RHEL 5 Xen server using ssh-agent (note that Kerberos
does not work).  We might fix this in future, but at the moment you're
somehow going to have to ensure that the oVirt node has a private key
which is listed in the authorized_keys in the RHEL 5 Xen server.  I
simply cannot imagine a user interface that is going to make this
usable.

I should also say that few people care about RHEL 5 Xen imports.
Citrix Xen imports OTOH, certainly, but those were out of scope for
current upstream development for RHEL 7.1.

Anyway, the user will have to specify:

 - hostname of RHEL 5 Xen server
 - username
 - password
 - name of the guest

There are various virsh commands you can run from VDSM to establish
whether conversion is likely to work, and to get a list of guests
which you can present to the user.

Physical machines
-----------------

See also: http://libguestfs.org/virt-p2v.1.html
[Update from previous email: I have now updated this page to contain
the latest documentation.]

Virt-v2v can import physical machines, but you have to boot the
separate virt-p2v ISO on the physical machine, and generally speaking
the process is directed from the physical machine.

This makes it quite unlike the other input sources.  (Users will still
be able to use the self-boot + '-o rhev' method, ie. import into the
Export Storage Domain, as with RHEL 6).

If oVirt can (or does?) run a PXE server, then it's possible to serve a
virt-p2v bootable image to physical machines, and it's also possible
to automate it from the PXE server side.
[http://libguestfs.org/virt-p2v.1.html#kernel-command-line-configuration]

Environment variables
---------------------

You may also want to set the following environment variables before
running virt-v2v:

LIBGUESTFS_BACKEND=direct

This is currently required for VMware and RHEL 5 Xen conversions owing
to a bug in libvirt (1134592) that was today pushed to RHEL 7.2.  You
should be able to drop this once libvirt is fixed.

TMPDIR=...

You might want to set this to control where large temporary files are
created during the v2v process.

Other environment variables that may affect virt-v2v are discussed on
both of these pages:
http://libguestfs.org/guestfs.3.html#environment-variables
http://libguestfs.org/virt-v2v.1.html#environment-variables

A note on the output mode
-------------------------

You're going to be using '-o vdsm -os /storage_domain' and the other
options: '--vdsm-image-uuid UUID', '--vdsm-vol-uuid UUID',
'--vdsm-vm-uuid UUID' [http://libguestfs.org/virt-v2v.1.html#options]

Implicit in the contract with '-o vdsm' is that VDSM is responsible
for creating the output directories, running virt-v2v as user 36:36,
and deleting the output directories if virt-v2v fails.

In this output mode virt-v2v doesn't create or clean up after itself
or try to chown files (unlike '-o rhev').

HTH,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html