[Libguestfs] Status of virt-v2v?

[Matthew Booth]

On Thu, 2013-09-05 at 09:31 -0600, Mike Latimer wrote:
> 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.

It turns out that progress logging during the conversion isn't all that
useful. This is because the profile of any conversion is dominated by
the copy process. And when I say dominated, I mean potentially hours to
copy guest data, followed by about 1 minute of conversion. It's
certainly not useful in real time, because the user will have wandered
off to get coffee long before the conversion process starts, and likely
won't see it!

Incidentally, you mention an 'analyzing' step. virt-v2v doesn't really
have one. It copies, then analyzes and converts in 1 go. One of the
design goals of guestconv is to allow us to split it into the stages you
suggest above by having a separate 'inspection' stage.

Matt