Re: [Libguestfs] [PATCH v2 4/4] v2v: in-place: request caps based on source config
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