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

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

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?)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

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.

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