Re: [ovirt-devel] virt-v2v intergration with vdsm

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