similar to: [v2v PATCH] docs: remove paragraph about VMware tools on Windows

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.

This patch is incomplete, but early feedback would be welcome. Rich.

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 > > >

The first patch was previously posted here: https://www.redhat.com/archives/libguestfs/2017-December/msg00018.html That patch hasn't changed except that I made the ‘input_transport’ variable type-safe. The second patch adds a significant new mode for liberating data from VMware: the ability to copy VMs over SSH directly from ESXi hypervisors. Although this requires enabling SSH access (a

Hi everybody, Wanted to hear your opinion and to receive a smart advice. I'm trying to use virt-v2v in order to convert ova image (exported from vcenter) to run on libvirt/kvm - all this inside a VM of fedora. The converted image is also a fedora. During the conversion process, in some point of libguestfs activity, I get double fault panic from L2 (printed as part of libguest output) and the

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]

https://bugzilla.redhat.com/show_bug.cgi?id=1441197

It turns out that RHEL 5 Xen conversions don't work if the source disk is located on a block device. See patch 1/4 for the gory details. This patch series proposes a new tool called virt-v2v-copy-to-local which essentially is a way to make new virt-v2v work like the old virt-v2v, ie. copy first, convert after. Of course this is very slow and would only be used as a last resort, but I

Hi, I'm looking for a way to use virsh to connect to vCenter/VCSA and do some simple management of the VM's in case of power loss (I'm planning to run the script upon UPS/apcd event of power failure). Looking through the virsh documentation, I didn't find 2 things: 1. Login through a script (I don't see any user/password, specially since VCSA for example requires to use

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

Thanks Bart. Unfortunately "The VIB module does not comply with the security recommendations imposed by VMWare. You lose VMWare support by installing this package." This pretty much rules out this option. :( We need vCenter support, as well. nomad On Thu, May 14, 2020 at 10:06 AM Bart J. Smit <bart at smits.co.uk> wrote: > This shuts down the hosts directly (by-passing

That's certainly on the list of options. I'm doing data gathering right now to see what options there are. I'd prefer not to rashly decide to run off in a direction only to discover this is already a Solved Problem. nomad On Thu, May 14, 2020 at 1:13 PM Bart J. Smit <bart at smits.co.uk> wrote: > What about the REST API to do a graceful shutdown of your VM’s and the >

On Fri, Sep 25, 2015 at 08:23:04AM -0700, angystardust wrote: > Hi Richard, > > i'm glad to see the suggestion i gave to the RH support in the > official documentation! :smile: > > You can also point to a vCenter by using this syntax: > > `ovftool --noSSLVerify vi://[USER]:[PASSWORD]@[VCENTER-HOST]/[DATACENTER-NAME]/vm/[VM-NAME] /path/to/file.ova` > > For an

Fix one dist issue, and almost all the builddir!=srcdir issues. (For the record, only 3 tests still fail in that setup.) Pino Toscano (3): libvirt-ocaml: add libvirt_c.h as source tests: fix path to sources of fake-virtio-win.iso tests: fix srcdir references bundled/libvirt-ocaml/Makefile.am | 1 + test-data/fake-virtio-win/Makefile.am | 2 +- tests/rhbz1232192.sh

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

This is built on top of the following patch series: https://www.redhat.com/archives/libguestfs/2019-April/msg00054.html Rich.

This enhances the existing VMX input support allowing it to be used over SSH to the ESXi server. The original command (for local .vmx files) was: $ virt-v2v -i vmx guest.vmx -o local -os /var/tmp Adding ‘-it ssh’ and using an SSH remote path gives the new syntax: $ virt-v2v \ -i vmx -it ssh \ "root@esxi.example.com:/vmfs/volumes/datastore1/guest/guest.vmx" \ -o local

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 LIBGUESTFS_HV=/home/shahar/git/qemu/x86_64-softmmu/qemu-system-x86_64 > > > > Is that sufficient? > > Yup, upstream qemu should

Fix some quoting issues by introducing Unicode quotes. Note this intentionally only affects end-user messages and documentation. Rich.

While trying to convert an OVA exported from VMware vSphere to libvirt using virt-v2v, I get the following error: virt-v2v: error: no installed kernel packages were found. Environment info: Base OS: 16.04.2 LTS (Xenial Xerus) Source VM OS: CentOS 7 libguestfs: 1.37.16 (built from source) Relevant logs are attached. Thanks, Zach