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

[Roman Kagan]

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?

> Alternately (and a bit more work): expose the requested guestcaps
> completely through the command line, eg:
> 
>   --request-block=[virtio|ide|best]
>   --request-net=[virtio|e1000|rtl8139|best]
>   --request-video=[qxl|cirrus|best]
> 
> where 'best' == None (I think?)

There can be no 'best' in --in-place mode: the upper level has already
made the decision on what devices to use, so v2v has just to obey.  The
command-line options for requested guestcaps do make sense either for
copying mode when you want to affect its decisions, or in inplace mode
if it's made not to parse the input VM config (and in the latter case
they have to be non-optional and unambiguous).

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.

Roman.