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

[Martin Kletzander]

On Fri, Oct 11, 2019 at 03:48:43PM +0100, Richard W.M. Jones wrote:
>On Fri, Oct 11, 2019 at 04:17:44PM +0200, Martin Kletzander wrote:
>> On Fri, Oct 11, 2019 at 01:29:53PM +0100, Richard W.M. Jones wrote:
>> >What would a tool which reused virt-v2v code and did what we really
>> >want look like?  The basic flow of objects in existing v2v/v2v.ml is:
>>
>> Ideally there would be distinction between metadata and disks, so
>> that I could specify separately for disks and metadata where do they
>> come from and where they should go.  That way we could do things
>> like "convert metadata from source to destination, but take disk
>> data from the destination already and keep them there" and other
>> things like that.
>
>Just want to point out that this particular operation is not possible
>since target metadata depends on the result of conversion, and it's
>not really possible to intuit it by looking at the converted disk.
>
>> >However there are some action items:
>> >
>> >(1) do_convert does not need the source parameter.  I think it could
>> >just be passed the .s_name field instead.
>> >
>> >(2) output#prepare_targets doesn't really need the source struct, but
>> >could probably get away with being passed just the .s_name field and
>> >maybe .s_hypervisor.
>> >
>> >(3) source.s_disks and the rest of the source struct seem to have
>> >sufficiently different usage that we can consider separating them.
>> >
>> >These changes would reduce coupling between stages.
>> >
>
>> To be honest I do not know what you are trying to do here.
>
>These changes are just to simplify the code and make it easier to do
>othe changes in future.
>
>> If that helps getting supported version of --debug-overlays, then
>> great.  But to make it absolutely clear, what --debug-overlays is so
>> close to what I wanted the whole time that the only better thing
>> than that would be --commit-overlays and the only thing that it
>> would help with would be that I don't have to run one easy command
>> per disk.  Given the only "problem" with --debug-overlays I can
>> think of is the fact that it is marked as unsupported.  Other than
>> that, I'm very happy with this patch.  And given the fact that it
>> does not need scary code changes it also feels safe to use.
>
>I'm trying to make something supportable from the point of view of
>upstream.  We can't get into a situation where a major user of the
>tool relies on debugging output and (as inevitably happens) we never
>get a chance to fix it.  Overlays are entirely an internal detail of
>how virt-v2v happens to work currently.
>

OK, that makes sense.  It helps with understanding your e-mail =) In that case
yes, integrating `qemu-img commit` into the process is better.  I might go
through your e-mail again to make sure I didn't miss anything.

Have a nice weekend.

>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-builder quickly builds VMs from scratch
>http://libguestfs.org/virt-builder.1.html
-------------- 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/20191011/c7555f0c/attachment.sig>