[ovirt-devel] virt-v2v intergration with vdsm

[Arik Hadas]

----- Original Message -----
> 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.

VDSM is not only responsible for creating the output directories but also the output files (we have to have it that way when the destination storage domain resides in block-based device). We'll probably need to use a technique that was used elsewhere, where output was streamed into those files. so virt-v2v won't create the output files.

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