11:53 a.m.
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.