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

[Kenneth Armstrong]

Dennis is spot on.

If I copy down the file straight from the ESX server's web interface,
it's quite quick.  However, when I try it through virt-v2v, the
process takes hours downloading/converting the same file.

The vmdk file in question is a sparse disk.  So I assume that virt-v2v
is expanding the disk out during the whole process?

-Kenny

On Fri, Mar 18, 2011 at 8:06 AM, Dennis Jacobfeuerborn
<dennisml at conversis.de> wrote:
> 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
>
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>