Re: [Libguestfs] Status of virt-v2v?

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.