[Libguestfs] [PATCH v2 4/4] v2v: in-place: request caps based on source config

[Richard W.M. Jones]

On Thu, Feb 25, 2016 at 08:41:38PM +0300, Roman Kagan wrote:
> On Thu, Feb 25, 2016 at 09:54:31AM +0000, Richard W.M. Jones wrote:
> > On Wed, Feb 24, 2016 at 05:33:44PM +0300, Roman Kagan wrote:
> > > Passing that on the command line makes sense for the copying mode,
> > > because in that mode there's no other place where to affect the choices.
> > > 
> > > In the in-place mode virt-v2v is given a VM with the configuration
> > > already converted and the choices made (with or without user
> > > interaction); v2v is only expected to tune the guest to work in that
> > > configuration.  So in that case rcaps are based on the source (==
> > > target) VM properties.
> > 
> > I think this makes 'virt-v2v --inplace' a bit less useful as a general
> > thing you can do with the tool.  Can we switch on this behaviour only
> > if there is a command line flag?  That would ensure that 'virt-v2v
> > --inplace' is a generally useful feature for people who want virt-v2v
> > to install the best drivers, while your use case is still possible (by
> > passing the flag).
> 
> What is the usecase for installing drivers not matching the actual
> hardware?

I see your point, although it assumes that the source hypervisor
is the destination hardware.

The use case that I have in mind is:

 - we have an agent running in the source guest which copies the hard
   disks of the guest over to destination, using some mechanism to do
   a consistent snapshot of the disks

 - the source shuts down

 - on the destination we run virt-v2v --inplace

 - we boot up the guest at the destination

However now you've explained it to me, I think what we need to do is
to document [in v2v/virt-v2v.pod] that in --inplace mode, the source
hypervisor metadata (eg. the source libvirt XML in -i libvirtxml mode)
is actually the final hardware that virt-v2v optimizes for.  I don't
think that was clear to me before, and it certainly won't be clear to
the end users, so it needs to be documented.

[...]
> BTW I just realized that my patch 3 is broken in that it doesn't
> distinguish between "no preference" (leaving the choice to convert(),
> aka "best") and "preference to do nothing".
> 
> I think the confusion comes from what I wrote before: mixing up decision
> making and actual guest tuning.  I'll have to think some more about it,
> but I'm tempted to factor out the guest tuning from the current v2v
> (which appears more of an orchestration kind of tool) into a separate
> lighter-weight module taking the directions from outside and making no
> choices of device types itself.

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