[Libguestfs] OpenStack output workflow

Wed Sep 26 10:05:17 UTC 2018

On Wed, Sep 26, 2018 at 11:39 AM Richard W.M. Jones <rjones at 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
> reasons.
>
> 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
> conceptually.
>
> 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.

Rich.
>
> --
> 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*

PRINCIPAL SOFTWARE ENGINEER

Red Hat - Solutions Engineering

fabien at redhat.com     M: +33 (0) 662 784 971 <+33662784971>

<http://redhat.com>  *TRIED. TESTED. TRUSTED.*

Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180926/00ce0e27/attachment.htm>