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 > 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@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
Rather than jumping to a solution, can you explain what the problem is that you're trying to solve? You need to do <X>, you tried virt-v2v, it doesn't do <X>, etc. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
[Adding Tomas Golembiovsky] On Wed, Sep 26, 2018 at 12:11 PM Richard W.M. Jones <rjones@redhat.com> wrote:> > Rather than jumping to a solution, can you explain what the problem > is that you're trying to solve? > > You need to do <X>, you tried virt-v2v, it doesn't do <X>, etc. >Well, that's mainly IMS related challenges. We're working on OpenStack output support and migration throttling and this implies changes to virt-v2v-wrapper. This is then the opportunity to think about virt-v2v-wrapper maintenance and feature set. It has been created in the first place to simplify interaction with virt-v2v from ManageIQ. The first challenge we faced is the interaction with virt-v2v. It's highly versatile and proposes a lot of options for input and output. The downside of it is that over time is becomes more and more difficult to know them all. And all the error messages are made for human beings, not machines, so providing feedback through a launcher, such as virt-v2v-wrapper, is difficult. The second challenge was monitoring the virt-v2v process liveliness and progress. For liveliness, the virt-v2v-wrapper stores the PID and checks that it's still present and when absent checks its return code for success (0) or failure (!0), and any other launcher could do the same. For progress, the only way to know what happens is to run virt-v2v in debug mode (-v -x) and parse the (very extensive) output. Virt-v2v-wrapper does it for us in IMS, but it is merely a workaround. I'd expect a conversion tool to provide a comprehensive progress, such as "I'm converting VM 'my_vm' and more specifically disk X/Y (XX%). Total conversion progress is XX%". Of course, I'd also expect a machine readable output (JSON, CSV, YAML…). Debug mode ensures we have all the data in case of failure, so I don't say remove it, but simply add specialized outputs. The third challenge was to clean up in case of virt-v2v failure. For example, when it fails converting a disk to RHV, it doesn't clean the finished and unfinished disks. Virt-v2v-wrapper was initially written by RHV team (Tomas) for RHV migrations, so it sounded fair(ish). But, extending the outputs to OpenStack, we'll have to deal with leftovers in OpenStack too. Maybe a cleanup on failure option would be a good idea, with a default to false to not break existing behaviour. The fourth challenge is to limit the resources allocated to virt-v2v during conversion, because concurrent conversions may have a huge impact on conversion host performance. In the case of an oVirt host, this can impact the virtual machines that run on it. This is not covered yet by the wrapper, but implementation will likely be based on Linux cgroups and tc. The wrapper also adds an interesting feature: both virt-v2v and virt-v2v-wrapper run daemonized and we can asynchronously poll the progress. This is really key for IMS (and maybe for others): this allows us to start as many conversions in parallel as needed and monitor them. Currently, the Python code forks and detaches itself, after providing the paths to the state file. In the discussion about cgroups, it was mentioned that systemd units could be used, and it echoes with the daemonization, as systemd-run allows running processes under systemd and in their own slice, on which cgroups limits can be set. About the evolution of virt-v2v-wrapper that I'm going to describe, let me state that this is my personal view and it endorses only myself. I would like to see the machine-to-machine interaction, logging and cleanup in virt-v2v itself because it is valuable to everyone, not only IMS. I would also like to convert virt-v2v-wrapper to a conversion API and Scheduler service. The idea is that it would provide an as-a-Service endpoint for conversions, that would allow creation of conversion jobs (POST), fetching of the status (GET), cancelation of a conversion (DELETE) and changing of the limits (PATCH). In the background, a basic scheduler would simply ensure that all the jobs are running. Each virt-v2v process would be run as a systemd unit (journald could capture the debug output), so that it is independent from the API and Scheduler processes. I know that I can propose patches for changes to virt-v2v, or at least file RFEs in Bugzilla (my developer skills and programing languages breadth are limited). For the evolved wrapper, my main concern is its housing and maintenance. It doesn't work only for oVirt, so having its lifecycle tied to oVirt doesn't seem relevant in the long term. In fact, it can be for any virt-v2v output, so my personal opinion is that it should live in the virt-v2v ecosystem and follow it's lifecycle. As for its maintenance, we still have to figure out who will be responsible for it, i.e. who will be able to dedicate time to it. Rich.> > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top >-- *Fabien Dupont* PRINCIPAL SOFTWARE ENGINEER Red Hat - Solutions Engineering fabien@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