On 29/01/10 19:33, Richard W.M. Jones wrote:
On Fri, Jan 29, 2010 at 06:05:10PM +0000, Matthew Booth wrote:
> This change adds the ability to import a guest and its storage from VMware's ESX
> server using the LibVirt connection.
>
> An example command line:
>
> virt-v2v -ic 'esx://yellow.marston/?no_verify=1' -op transfer RHEL5-64
>
> This will import the guest RHEL5-64 from esx server yellow.marston, copying its
> storage to a local pool called transfer.
>
> Sys::VirtV2V::Connection is refactored to be a superclass. Subclasses are now
> created explicitly by virt-v2v.pl rather than using a generic instantiate
> mechanism.
>
> Sys::VirtV2V::Connection::LibVirt knows explicitly about ESX, and will use the
> new Sys::VirtV2V::Transfer::ESX to fetch its storage.
>
> virt-v2v.pl is updated to reflect the other changes.
I didn't look at this in great detail, but some quick comments:
- get_guest_devices function has disappeared. I didn't quite get why.
It's functionally replaced by get_local_storage() in Connection.
- get_volume looks complicated. I wonder how stable those ESX paths
are
and whether there are configurations which have other paths
(however it does seem correct for my ESX 4 server).
I've also been worrying about that. However, the path-name munging is
relatively uncomplicated, so if it turns out that scheme is too
simplistic it shouldn't be hard to update. What makes Transfer::ESX look
worse that it needs to is the LWP api. IIRC I use 3 different callbacks
to get the job done.
Matt