[Libguestfs] Status of virt-v2v?

[Matthew Booth]

On Tue, 2013-09-03 at 17:10 -0600, Mike Latimer wrote:
> On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote:
> > Even better, there is a repo: https://github.com/mdbooth/guestconv
> 
> Excellent. Thanks for the pointer.
> 
> > Matt - can you push your latest commits, or is there a more canonical
> > repo that Mike can look at?
> 
> The last changes in the repo seem to be from back in June. Is guestconv 
> expected to completely replace virt-v2v in RHEL7?

Yeah, I've been a bit lax in pushing stuff to guestconv. Also,
development on it hasn't gone nearly as quickly as I'd have liked
lately. I've just gotten back to it, though. I'm in the middle of a
change right now, but I'll try to get it pushed RSN.

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.

> > > I've got a couple of patches against the current code base, and am
> > > wondering if they will still be considered for inclusion.
> > 
> > Yes, for virt-v2v (or guestconv if you want too).  Post patches on
> > this mailing list.

+1. I've been adding to virt-v2v this week.

> Great. I've got some code which adds support for openSUSE/SLES into virt-v2v 
> (based on the RedHat.pm converter). Along the way, I ran into a couple of 
> small issues which affect RHEL as well. I'll post those changes here for 
> review, and possibly begin a discussion surrounding the SUSE side of things.

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.

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...

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. 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.

If you have any ideas on what the second set is, that would be very
interesting.

Thanks,

Matt