[Libguestfs] Status of virt-v2v?

[Mike Latimer]

On Thursday, September 05, 2013 12:00:44 PM Matthew Booth wrote:
> guestconv is not intended to completely replace virt-v2v. Broadly
> speaking, virt-v2v does 2 things:
> 
> 1. Move guests between 2 hypervisors.
> 2. Make changes to the guest required for a new hypervisor.
> 
> The second is unique to virt-v2v, the first has other tools out there.
> guestconv will only replace the second bit, and will expose this
> functionality as a library. guestconv will also target more combinations
> of source and target hypervisor, and allow more control over the
> conversion process.

Thanks for the clarification. I'll keep tabs on the repo, and contribute from 
the SUSE side.

> Yes, please. You had some questions in another email about grubby.
> There's no fundamental reason to require grubby. In fact, if you look
> back through the git history we didn't originally require it. However,
> it simplified things because it supports both grub legacy and grub 2
> (whose configuration has been classified as a form of torture by the
> UN). I can't think of any good reason you couldn't install grubby early
> in the conversion process and use it later. However, I would *not*
> re-use the user-custom installation for this. If installation of grubby
> is critical to the conversion process, give it its own entry in
> virt-v2v.db.

Yes, after the grub2 config segment on C-SPAN last night, I'd rather just let 
grubby take care of the dirty work.

> The pre-convert idea is one we've tried to avoid in the past, although
> I'm by no means 100% against it. If we decided to go fully down that
> route, it would certainly allow us to remove a ton of code and greatly
> simplify testing. Hmm...

Ok. I'll finish the SUSE converter with one of those solutions and we can 
discuss it further after it's posted.

> You also mentioned the logging. Yes, logging is sparse in virt-v2v; it
> will be better in guestconv. It's lame in virt-v2v because we didn't
> consider it important early, and didn't retrofit it later. However, you
> have to consider what the logging is for. If it's just for debugging,
> nothing is likely to beat LIBGUESTFS_TRACE. 

LIBGUESTFS_TRACE is more than enough to monitor the conversion itself. I was 
specifically thinking a little higher level anyway.

> I would keep logging to:
> 1. Debugging information which won't be captured by LIBGUESTFS_TRACE,
> because it doesn't involve a libguestfs api call.
> 2. Information about the conversion which is of use to the end user.

I definitely agree that additional logging would be helpful in the above areas. 
Initially, I just wanted to add some basic progress type of messages as you go 
through the virt-v2v stages. (Connecting to host, analyzing guest, copying 
storage, inspecting, converting, creating...). I have also thought about a 
summary of the conversion process, and what might be useful there. I'll flush 
my thoughts out and start a new thread for additional comments.

Thanks,
Mike