[virt-tools-list] virt-v2v question involving esx

[Dennis Jacobfeuerborn]

On 03/18/2011 11:34 AM, Matthew Booth wrote:
> On 17/03/11 19:27, Richard W.M. Jones wrote:
>> [Adding Matt]
>>
>> On Wed, Mar 16, 2011 at 02:59:40PM -0400, Kenneth Armstrong wrote:
>>> I have a vm on an esx server that I want to convert using virt-v2v. I
>>> know that it can connect to the esx server and copy the vmdk files
>>> down to do its conversion, but can I just use wget or something like
>>> that to copy the vmdk files down first, then use virt-v2v to convert
>>> the vm?
>>>
>>> The reason that I ask is that it would be better for me to do it this
>>> way, so that after I copy the vm files down, I can start the vm back
>>> up and let it be used while virt-v2v does the conversion on the copied
>>> image files. I like virt-v2v, but it takes a long time to do it's job
>>> with the copying.
>
> Are you saying that wget is substantially faster than virt-v2v's copying? I
> ask because virt-v2v uses the same http interface to retrieve the image. It
> actually streams and writes directly to the target destination, so unless
> the target destination is slow, I wouldn't expect this to save you a
> significant amount of time. The actual conversion process usually takes
> about a minute, so the copying time dominates almost completely.
>
> It is possible to do what you're asking, but it's a hassle. You'd need to
> obtain the storage files, create a local libvirt XML file which points to
> the local copies, then run virt-v2v using the libvirtxml input method.

If the vmdk file is sparse then you might end up copying a lot less data 
compared to a virt-v2v copy and since as you point out the copying is the 
thing that dominates the migration time that can potentially be a big win.
It would be nice if virt-v2v had an option to not copy the block device but 
instead the contents of a filesystem but that would probably make things 
much more complicated since you'd have to support all kinds of filesystems, 
LVM, potentially also copy UUID's etc., etc.

Regards,
   Dennis