On Wed, Sep 26, 2018 at 11:39 AM Richard W.M. Jones <rjones@redhat.com> wrote:
On Wed, Sep 26, 2018 at 09:57:22AM +0200, Fabien Dupont wrote:
> Hi,
> There has been discussion about the OpenStack output and Richard asked for
> a public thread on this list, so here it is.
> For v2v from VMware to RHV, there is a Python script that does some extra
> steps to create the virtual machine after the disks have been converted. We
> want to have the same behavior for OpenStack, i.e. have virt-v2v create the
> instance once the volumes have been created.

Note that for RHV we create *but do not start* the virtual machine.

In fact virt-v2v doesn't start the virtual machine on any output, with
the exception of the ‘--qemu-boot’ flag (which we remove in RHEL since
it's essentially a debugging feature).

So I don't necessarily accept the premise that virt-v2v should start
the VM on OpenStack.  One reason not to is that the VM might not have
been running on the source, and converting a VM should not change its
state from shutdown to running for what I think are fairly obvious

Complicating this is that OpenStack itself doesn't seem to have a
concept of a VM which is created but not running (in this way it is
different from libvirt and RHV).

We currently create Cinder volume(s) with the VM disk data, plus image
properties attached to those volume(s), plus other volume properties
[NB: in Cinder properties and image properties are different things]
which is sufficient for someone else to start the instance (see
virt-v2v(1) man page for exactly how to start it).

I do agree that we ask virt-v2v to do one more thing compared to RHV,
which is start the VM. But, virt-v2v doesn't really start the VM: it creates it,
then OpenStack starts it once created. I think we can fairly consider that
a user converting a VM, not only disks, from VMware to OpenStack will know
it and I think we should emphasize that in the OpenStack output documentation.

Also, I think it would be nice option for RHV to have a -oo start-vm option that
allows starting the VM after conversion. But I might be pushing too much ;)

> For that, I've written a Python script [1] that takes a JSON file (sample
> here [2]) as input. I expect this JSON input to be generated by virt-v2v
> openstack output module, from the command line options and the volumes ids
> generated during conversion.
> Here are the options I think we should have for the OpenStack output:
> -o openstack
> -oo os-auth-url='http://controller.example.com:5000/v3'
> -oo os-user-domain-name='Default'
> -oo os-project-name='v2v-project'
> -oo os-username='admin'
> -oo os-password='secret'
> -oo server-id='01234567-89ab-cdef-0123-456789abcdef'
> -oo destination_project_id='01234567-89ab-cdef-0123-456789abcdef'
> -oo volume_type_id='01234567-89ab-cdef-0123-456789abcdef'
> -oo flavor_id='01234567-89ab-cdef-0123-456789abcdef'
> -oo
> security_groups_ids='01234567-89ab-cdef-0123-456789abcdef,01234567-89ab-cdef-0123-456789abcdef'
> --mac 01:23:45:67:89:ab:network:01234567-89ab-cdef-0123-456789abcdef
> You'll see that the --mac option is not specific to OpenStack, but it shows
> how it would look like with a network id. And it should be passed to the
> post-conversion script.
> The translation to JSON is pretty straight forward and should not be
> difficult. We simply have to agree on the JSON keys we expect and the where
> the new -oo keys go. Also, the script is quite simple and relies on
> OpenStack Python SDK, which is also used by the OpenStack CLI, so no
> additional dependencies are required and it should be easy to maintain.
> [1]
> https://gist.github.com/fdupont-redhat/934b3efb6d66a991a80149235066d7d7#file-post_conversion-py
> [2]
> https://gist.github.com/fdupont-redhat/934b3efb6d66a991a80149235066d7d7#file-test-migration-json

I'm still confused about how this fits with virt-v2v, even

Why don't you just run virt-v2v with the options you want, then
examine the resulting Cinder volumes, extract the properties and image
properties and run the VM using those properties?

Did you look at a converted VM and see the properties and image
properties that we are setting?

That would mean moving that part into ManageIQ or virt-v2v-wrapper. But, I don't
see why virt-v2v-wrapper is not part of librguest/virt-v2v as it is not limited to RHV
conversions anymore. It adds a API-like interface to virt-v2v, as well as monitoring
capabilities that are really valuable. I'm thinking about a evolution of virt-v2v-wrapper,
and I will probably start a new thread for that.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org


Fabien Dupont


Red Hat - Solutions Engineering

fabien@redhat.com     M: +33 (0) 662 784 971


Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps