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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
