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
signature.asc
Description: PGP signature
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
