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