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

Martin Kletzander mkletzan at redhat.com
Wed Oct 16 13:33:10 UTC 2019


On Tue, Oct 15, 2019 at 06:26:23PM +0100, Richard W.M. Jones wrote:
>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.
>

I agree with both of you, as I also mentioned this idea in one of my previous
e-mails.  Of course I do not know how exactly to do that nicely and Rich will
know way more on how to approach this.

Martin

P.S.: If you want some ideas for some usage scenarios and you cannot think of
      any, just let me know.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20191016/982eecfc/attachment.sig>


More information about the Libguestfs mailing list