[Libguestfs] [PATCH] v2v: Output saved overlays in a machine-readable fashion

Roman Kagan rkagan at virtuozzo.com
Tue Oct 15 16:53:03 UTC 2019


On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
> Stepping back I think the problem is we're shoehorning features into a
> tool (virt-v2v) which was designed to do cold conversions, and was
> never meant to do either warm or in-place conversions.  The tool was
> hacked a while back for in-place but that mode is very awkward to use
> and we have never enabled it in RHEL for good reason.

As I'm guilty for introducing --in-place, let me chime in with my 2c and
humbly disagree with it being awkward to use.  I think the only thing
that's awkward is its tight integration into virt-v2v; it'd make more
sense being a separate tool whose sole purpose would be to tune the
guest to be bootable/operational in the provided configuration.

Such a tool (let's call it, say, virt-adopt or virt-adapt, depending on
whose POV you take, the guest's or the host's :) could have a number of
benefits:

1) it can be used outside of the current virt-v2v, e.g.

   a) v2v where the rest of migration is taken care of by something
      else.  E.g. we use it to migrate from our own older releases that
      used a different hypervisor, and we're sure to do a better job
      converting configurations and copying data than the generic tool.
      Overall data/metadata migration is the place where plenty of
      customization can be necessary, and the monolithic tool is too
      rigid for that, so we've had a few other cases where it was easier
      to write custom migration code and call the tool to adopt the
      resulting guest.  In particular, QCOW2 overlays are not always
      possible or conveninent, data migration via the source hypervisor
      control url is not necessarily the fastest, and so on.

   b) we use it to restore backups created with the older releases which
      used incompatible virtual hardware.

   c) every now and then I wanted to change the hardware configuration
      of an existing VM in an incompatible way, like changing the
      chipset, the type of the storage or network controller, etc, and
      this tool came in handy.

2) it can allow splitting the current virt-v2v into reusable steps.
   E.g. it's a pity, having migrated a huge guest disk image, to find
   out that due to some minor network misconfiguration on the host you
   can't run yum in the guestfs appliance to install some missing bits
   and thus can't complete the conversion, so, once the problem is
   fixed, you have to start over.

3) it fits better with the libguestfs' purpose, which is to poke in the
   guest's files.  As a result, in particular, it has smaller testing
   scope, and is thus easier to keep tested.  (I wonder how many
   contributors have the opportunity to test all virt-v2v's input and
   output hypervisor combinations.)

The only downside I see is that it requires some work to be done, and
I'm short of spare cycles to do that :(

> What you want -- copy done elsewhere, convert in place, create metadata --
> is a very different flow.  It could look something like this:
> 
> * let overlays = create_overlays source.s_disks in
>   let g = Guestfs.guestfs () in
>   populate_overlays g overlays
>   let inspect = Inspect_source.inspect_source g in
>   let guestcaps = do_convert g inspect output in
>   let targets = output#prepare_targets overlays in
>   for each overlay: qemu-img commit it
>   output#create_metadata source targets guestcaps inspect

FWIW our scenarios look somewhat different:

1) transfer vm disks and metadata
2) (optional) inspect migrated guest
3) create target vm based on (1) and (2)
4) (optional) snapshot target vm (using overlays or whatever is appropriate)
5) "adopt" target vm (using virt-v2v --in-place)
6) (optional) boot target vm and let firstboot scripts run
7) (optional) merge snapshots with the original disks
8) release target vm to user

Note, in particular, that step (5) makes no decisions re. the eventual
vm configuration; they are all made at step (3).  Restore from old
backups just changes step (1).

Thanks, and sorry for the long mail without patches,
Roman.




More information about the Libguestfs mailing list