Re: [Libguestfs] [PATCH] v2v: Output saved overlays in a machine-readable fashion

On Tue, Oct 15, 2019 at 04:53:03PM +0000, Roman Kagan wrote: > On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote: > > Stepping back I think the problem is we're shoehorning features into a > > tool (virt-v2v) which was designed to do cold conversions, and was > > never meant to do either warm or in-place conversions. The tool was > > hacked a while back for in-place but that mode is very awkward to use > > and we have never enabled it in RHEL for good reason. > > As I'm guilty for introducing --in-place, let me chime in with my 2c > and humbly disagree with it being awkward to use. I think the only > thing that's awkward is its tight integration into virt-v2v; it'd > make more sense being a separate tool whose sole purpose would be to > tune the guest to be bootable/operational in the provided > configuration. My original comments there are rather rude. What I should have said is the use of the input metadata (eg. --inplace -i libvirtxml) as a kind of configuration file for selecting the rcaps (eg. whether to install virtio drivers) are somewhat non-obvious, although as you say in the context of virt-v2v that's all that can be done. I would - same as you - like to split out virt-v2v much more, into more streamlined tools (but without breaking backwards compatibility or removing features). Still don't know how, but I'll read the rest of your email in more detail as part of thinking about this.