On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote:> Even better, there is a repo: https://github.com/mdbooth/guestconvExcellent. 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?> > 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.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. Thanks, Mike
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
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