On Wed, Sep 26, 2018 at 11:39 AM Richard W.M. Jones <rjo...@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 fab...@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
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
