similar to: [PATCH] Connection: Handle case of cdrom with no <source> element

Also changes command line parsing to require a pool to be specified when using libvirt output, meaning storage will always be copied. --- MANIFEST | 1 + lib/Sys/VirtV2V/Connection.pm | 74 +++++++++--------- lib/Sys/VirtV2V/Connection/LibVirt.pm | 18 +++-- lib/Sys/VirtV2V/Connection/LibVirtXML.pm | 11 ++- lib/Sys/VirtV2V/Target/LibVirt.pm

Move all target-specific functionality into its own module in preparation for output to RHEV. --- MANIFEST | 1 + lib/Sys/VirtV2V/Connection.pm | 46 ++--- lib/Sys/VirtV2V/Converter.pm | 138 +------------ lib/Sys/VirtV2V/Target/LibVirt.pm | 419 +++++++++++++++++++++++++++++++++++++ lib/Sys/VirtV2V/Transfer/ESX.pm | 91 +++------ po/POTFILES.in

We were assuming that guests wouldn't use multiple interfaces, or if they did, drive letters wouldn't clash between the interfaces. An ESX guest with a CDROM device breaks this because hard disks will be presented a SCSI, starting at sda, and CDROM devices are presented as IDE, starting at hda. This is in contrast to QEMU, which starts at hdc by default. Firstly, this change causes disks

This patch refactors the data transfer code with several goals: * Have a common read(source)/write(target) loop so that common processing can happen in the middle of it, e.g. format change/progress bar * Provide volume metadata to transfers to allow smarter reading/writing, e.g. of sparse files * Simplify the data transfer code The patch *isn't* NFC because there are some minor behaviour

Specifically fixes the issue where <script path='vif-bridge'/> would be corrupted rather than removed properly. Makes metadata conversion less generic. --- lib/Sys/VirtV2V/Converter.pm | 144 +++++++++++++++++++++--------------------- 1 files changed, 73 insertions(+), 71 deletions(-) diff --git a/lib/Sys/VirtV2V/Converter.pm b/lib/Sys/VirtV2V/Converter.pm index a6eba45..64a5a46

If a user accidentally passed a valid XML document to the LibvirtXML which wasn't actually a libvirt domain XML document, they would end up getting obtuse errors from a libguestfs library. This change does 2 sanity checks: 1. After parsing a the XML document, check /domain/name exists. 2. Check that the domain defines some storage The second check is generally useful, as we can't

We now always copy a guest during conversion, meaning this tool is no longer required. --- Build.PL | 2 +- MANIFEST | 2 - lib/Sys/VirtV2V.pm | 9 +- lib/Sys/VirtV2V/Connection.pm | 1 - po/POTFILES.in | 1 - snapshot/run-snapshot-locally | 43 -- snapshot/v2v-snapshot.pl | 931

This removes another chunk of functionality from GuestOS. --- MANIFEST | 1 + lib/Sys/VirtV2V/Config.pm | 339 +++++++++++++++++++++++++++++++++++++ lib/Sys/VirtV2V/Converter.pm | 56 +----- lib/Sys/VirtV2V/GuestOS.pm | 94 ---------- lib/Sys/VirtV2V/GuestOS/RedHat.pm | 46 ++++-- v2v/virt-v2v.pl | 96 +---------- 6 files

If a volume is not an exact multiple of 512 bytes, qemu-img will report its size rounded down to a 512 byte boundary. However, when copying, the file is still read until EOF, which will return more data than was expected. This change prevents that causing a failure in itself. The situation is still not resolved, however, as there are still situations where this will cause a failure. For example,

Previously, only the LibVirtXML connection translated network and bridge names in imported metadata. This change moves this functionality in Converter, making it available to LibVirt connections as well. At the same time, the format of the config file is switched to XML. The primary driver for this is that the allowable syntax of a foreign network/bridge name is not known. Rather than create a

This change updates a guest which uses Xen's xvc0 to use ttyS0 instead. In a related change, it also makes a console a 'standard device' will always be configured. --- lib/Sys/VirtV2V/Converter.pm | 5 +++- lib/Sys/VirtV2V/Converter/Linux.pm | 46 ++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 1 deletions(-) diff --git

Previously we used SCSI when VirtIO wasn't available. KVM's SCSI support is not as mature as its IDE support, and SCSI isn't supported at all in RHEV. --- lib/Sys/VirtV2V/Converter.pm | 50 +++++++++++------- lib/Sys/VirtV2V/Converter/Linux.pm | 19 ++++--- lib/Sys/VirtV2V/GuestOS/RedHat.pm | 100 ++++++++++++++++++++---------------- 3 files changed, 100 insertions(+), 69

This will allow use of raw data from os description in addition to libvirt XML when writing guest output. --- lib/Sys/VirtV2V/Target/LibVirt.pm | 2 +- lib/Sys/VirtV2V/Target/RHEV.pm | 2 +- v2v/virt-v2v.pl | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/Sys/VirtV2V/Target/LibVirt.pm b/lib/Sys/VirtV2V/Target/LibVirt.pm index

Previously, only the LibVirtXML connection translated network and bridge names in imported metadata. This change moves this functionality in Converter, making it available to LibVirt connections as well. At the same time, the format of the config file is switched to XML. The primary driver for this is that the allowable syntax of a foreign network/bridge name is not known. Rather than create a

With this patchset I have successfully[1] imported a RHEL 5 guest directly from ESX with the following command line: virt-v2v -ic 'esx://yellow.marston/?no_verify=1' -op transfer RHEL5-64 Login details are stored in ~/.netrc Note that this is the only guest I've tested against. I haven't for example, checked that I haven't broken Xen imports. Matt [1] With the exception of

The following patches are where I'm currently at with ESX support. I can now import a domain from ESX along with its storage. Note that I'm not yet doing any conversion. In fact, I've never even tested past the import stage (I just had an exit in there). The meat is really in the 4th patch. The rename of MetadataReader->Connection was because the Connection is now really providing

RHEV will fail to start a guest with more than one VirtIO disk marked as bootable. The previous behaviour of V2V simply marked all disks as bootable, intending to follow the behaviour of libvirt's qemu driver. However, libvirt's qemu driver actually only marks the first disk specified in the domain XML (which may or may not be Xda) as bootable. This change updates the RHEV output to follow

Currently virt-v2v attempts to create an iso containing all software referenced in the config file before starting. If any software isn't available it displays an error and exits immediately. With this change it will ignore software which isn't available at iso creation time. Instead, it will only display an error if the unavailable software is actually required. This is much kinder to

We previously wouldn't create a Config object if no config file was specified. This change ensures that a Config object is always created, but will do nothing interesting if there is no config file. Apart from being slightly cleaner, this allows information provided by Config to be later supplied from the command line instead. --- lib/Sys/VirtV2V/Config.pm | 34

A 32bit VMware host will boot a 64bit OS. However, 32bit KVM won't. This means that if you accidentally selected a 32bit machine type at VM creation time on ESX, then installed a 64bit OS, chances are you won't notice until you convert it and it doesn't work any more. To get round this, we always use the detected architecture of the OS if it's available. This will mean that your