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

[Roman Kagan]

On Thu, Feb 25, 2016 at 06:42:30PM +0000, Richard W.M. Jones wrote:
> 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.

Right.  That's the scheme that we think fits the best with our usecase.

> 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

That sounds more like p2v.  But yes, --in-place mode would fit this
case, too, and would still mean the same: poke in the guest to make it
boot and run in the new hardware.

> 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.

OK makes perfect sense, I'll try to come up with something
comprehensible.

> > 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've stumbled upon another issue: v2v assumes that the source VM
configuration represents the original hardware which matches the guest
configuration.  More specifically, the conversion of older Linuxen which
used device files by names for hard disks and partitions depends on
that.  I'm not sure how reliable that was and what to do with it now.
Researching...

Roman.