similar to: Re: v2v: Mention ovftool in the man page as a way to create OVA files.

virt-v2v is capable of accessing ESXi hypervisors now. There is only one remaining use of this tool - when converting from Xen hypervisors over ssh which are using host block devices for storage. --- v2v/virt-v2v-copy-to-local.pod | 27 ++------------------------- 1 file changed, 2 insertions(+), 25 deletions(-) diff --git a/v2v/virt-v2v-copy-to-local.pod b/v2v/virt-v2v-copy-to-local.pod index

On Sun, Sep 21, 2014 at 04:16:59PM +0300, Shahar Havivi wrote: > On 17.09.14 10:02, Richard W.M. Jones wrote: > > On Wed, Sep 17, 2014 at 10:58:18AM +0300, Shahar Havivi wrote: > > > On 16.09.14 15:09, Richard W.M. Jones wrote: > > > > On Tue, Sep 16, 2014 at 05:06:57PM +0300, Shahar Havivi wrote: > > > > > I am using upstream qemu while using this

On Wed, Sep 17, 2014 at 10:58:18AM +0300, Shahar Havivi wrote: > On 16.09.14 15:09, Richard W.M. Jones wrote: > > On Tue, Sep 16, 2014 at 05:06:57PM +0300, Shahar Havivi wrote: > > > I am using upstream qemu while using this local variables: > > > export PATH=/home/shahar/git/qemu:$PATH > > > export

On 17.09.14 10:02, Richard W.M. Jones wrote: > On Wed, Sep 17, 2014 at 10:58:18AM +0300, Shahar Havivi wrote: > > On 16.09.14 15:09, Richard W.M. Jones wrote: > > > On Tue, Sep 16, 2014 at 05:06:57PM +0300, Shahar Havivi wrote: > > > > I am using upstream qemu while using this local variables: > > > > export PATH=/home/shahar/git/qemu:$PATH > > >

On Wed, Oct 14, 2015 at 04:39:31PM +0200, Kevin COUSIN wrote: > Hi list, > > Is it possible to import VM from vSphere 4 with virt-v2v ? I use the > p2v ISO but I want to automate process. I don't think anyone has tested it as we only bother with vSphere >= 5, but it should work, assuming the guest is supported. You shouldn't need to use virt-p2v, plain virt-v2v should

On Mon, Dec 22, 2014 at 02:03:50PM +1100, Ben Hooper wrote: > Hi, > > I am encountering an issue with virt-v2v where I need to authenticate to the vCenter as DOMAIN\user. > > I have tried the following with the resulting errors: > > 1. 'virt-v2v -v -x -ic 'vpx://vcenter/Datacenter/cluster_name/esx_server?no_verify=1' vm_name -o local -of raw -os /tmp' >

Thanks Richard, seems to work well. Cheers, Ben. > On 22 Dec 2014, at 7:50 pm, Richard W.M. Jones <rjones@redhat.com> wrote: > >> On Mon, Dec 22, 2014 at 02:03:50PM +1100, Ben Hooper wrote: >> Hi, >> >> I am encountering an issue with virt-v2v where I need to authenticate to the vCenter as DOMAIN\user. >> >> I have tried the following with the

Starting from libguestfs/virt-v2v 1.39.12, virt-v2v attempts to uninstall the VMware tools from Windows guests, so there is no need to remove them manually before the conversion. Thanks to: Ming Xie. --- docs/virt-v2v-input-vmware.pod | 36 ---------------------------------- 1 file changed, 36 deletions(-) diff --git a/docs/virt-v2v-input-vmware.pod b/docs/virt-v2v-input-vmware.pod index

When parsing OVA files we have to work backwards to whether the original VMware object was a network or a bridge. It seems as if the presence of <rasd:Connection> is sufficient. I dropped the use of <rasd:ElementName> since it is literally just an internal name for the network element, and is not significant in how the network is used. Also update documentation because you must use

v2: - 1/3: same as in previous version - 2/3: add check for libvirt version - 3/3: restore the disabled test The libvirt patch [2] that should fix our problem with 'raw' driver that is mentioned in [1] was merged. To realy fix things, there is at least one thing we have to change on our side. We have to be explicit about the driver in the JSON we generate. [1]

Hi, I am encountering an issue with virt-v2v where I need to authenticate to the vCenter as DOMAIN\user. I have tried the following with the resulting errors: 1. 'virt-v2v -v -x -ic 'vpx://vcenter/Datacenter/cluster_name/esx_server?no_verify=1' vm_name -o local -of raw -os /tmp' - prompted for username password - entered 'DOMAIN\User' as username - successfully

We don't have to always extract all files from the OVA archive. The OVA, as defined in the standard, is plain tar. We can work directly over the tar archive if we use correct 'offset' and 'size' options when defining the backing file for QEMU. This leads to improvements in speed and puts much lower requirement on available disk space. Signed-off-by: Tomáš Golembiovský

We don't have to always extract all files from the OVA archive. The OVA, as defined in the standard, is plain tar. We can work directly over the tar archive if we use correct 'offset' and 'size' options when defining the backing file for QEMU. This leads to improvements in speed and puts much lower requirement on available disk space. Signed-off-by: Tomáš Golembiovský

Previously posted: https://www.redhat.com/archives/libguestfs/2018-November/msg00000.html https://www.redhat.com/archives/libguestfs/2018-November/msg00001.html This completes the split and rewrite of the virt-v2v manual to make it much simpler to understand and digest. Rich.

We have to be explicit about the drivers in backing file JSON in order for libvirt to work. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/input_ova.ml | 1 + v2v/test-v2v-i-ova-subfolders.expected2 | 2 +- v2v/test-v2v-i-ova-tar.expected2 | 2 +- v2v/test-v2v-i-ova-two-disks.expected2 | 4 ++-- 4 files changed, 5 insertions(+), 4

On Mon, 21 Nov 2016 16:21:02 +0100 Pino Toscano <ptoscano@redhat.com> wrote: > On Saturday, 12 November 2016 16:37:52 CET Tomáš Golembiovský wrote: > > We don't have to always extract all files from the OVA archive. The OVA, > > as defined in the standard, is plain tar. We can work directly over the > > tar archive if we use correct 'offset' and

On Fri, Mar 23, 2018 at 12:35:36PM +0100, Pino Toscano wrote: > So far v2v did not read the model of network interfaces, resulting in > "virtio" as the model for such interfaces. > > Start reading the model, if available, mapping only E1000 for now. Looks sensible, ACK. > There are also other models, e.g. PCNet32 or VmxNet3, but they are > ignored for now: reading

On Monday, 6 March 2017 16:08:59 CET Richard W.M. Jones wrote: > Test: > - Bad SHA1 sum > - Bad SHA256 sum > - Invalid lines in manifest (x2) > - Good checksum and manifest > > These tests were originally written by Tomáš Golembiovský. All I have > done is to integrate them into the virt-v2v test suite. > --- > .gitignore | 1 +

If the guest has no <Name> element in the OVF, previously we chose "default" as the name. This changes that so it uses a name derived from the basename of the OVA file instead. For example: virt-v2v -i ova /path/to/myguest.ova [...] would use "myguest" as the name (assuming no <Name> was present). Modifies the behaviour of commit

On Thursday 19 May 2016 17:26:12 Cédric Bosdonnat wrote: > Some ova files have their ovf and other files inside a folder rather > than at the root of the tarball. Consider the paths relative to the > ovf file to cover this case too. > --- Ouch... this standard is getting more funky implementations, I see... what is the producer of this kind of ova? A couple of notes below. >