Hi, I have recently been looking into virt-v2v, and noticed the mention of an upcoming rewrite in a few places. Is there a roadmap or post someplace that describes the future of this project? I've got a couple of patches against the current code base, and am wondering if they will still be considered for inclusion. Thanks, Mike
On Tue, Sep 03, 2013 at 09:29:49AM -0600, Mike Latimer wrote:
Hi,
I'll make some advisory comments, but you really need to talk to Matt Booth (CC'd - or mdbooth on #libguestfs).
I have recently been looking into virt-v2v, and noticed the mention of an upcoming rewrite in a few places. Is there a roadmap or post someplace that describes the future of this project?
Even better, there is a repo: https://github.com/mdbooth/guestconv Matt - can you push your latest commits, or is there a more canonical repo that Mike can look at?
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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
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?
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
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
On Thursday, September 05, 2013 04:47:09 PM you wrote:
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!
Very good points.
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.
Yes, the 'analyzing' step I was referring to was really just between connecting to the source, and beginning the storage copy. You can error out here (if the guest is running, or already exists on the target), and I thought some indication of what was going on would be useful. Progress messages of some form seem to be useful before the file copy starts. For example, if SSH keys are not in use, you can get two password prompt in a row, which can be a bit confusing. (Anyone doing a lot of this would certainly have SSH keys in place though.) The remaining messages might be better kept in a summary fashion though... I'll think about it from that perspective. -Mike
participants (3)
-
Matthew Booth -
Mike Latimer -
Richard W.M. Jones