similar to: [v2v PATCH] docs/virt-v2v: document libvirt system instance startup

On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: > It has frequently tripped us up that on RHEL / Fedora, installing the > right set of libvirt RPMs (such as the one pulled in by > "libvirt-daemon-kvm") does not result in an immediately running libvirt > system instance. Document the need, and the simplest method, for starting > libvirt up manually. >

It has frequently tripped us up that on RHEL / Fedora, installing the right set of libvirt RPMs (such as the one pulled in by "libvirt-daemon-kvm") does not result in an immediately running libvirt system instance. Document the need, and the simplest method, for starting libvirt up manually. Thanks: Daniel Berrang? Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024

On 6/28/23 12:05, Richard W.M. Jones wrote: > On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: >> It has frequently tripped us up that on RHEL / Fedora, installing the >> right set of libvirt RPMs (such as the one pulled in by >> "libvirt-daemon-kvm") does not result in an immediately running libvirt >> system instance. Document the need, and the

On Wed, Jun 28, 2023 at 01:31:53PM +0200, Laszlo Ersek wrote: > On 6/28/23 12:05, Richard W.M. Jones wrote: > > On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: > >> It has frequently tripped us up that on RHEL / Fedora, installing the > >> right set of libvirt RPMs (such as the one pulled in by > >> "libvirt-daemon-kvm") does not result

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024 v1 was here: <https://listman.redhat.com/archives/libguestfs/2023-June/031910.html>. Make any "chown_for_libvirt_rhbz_1045069" failure a hard one; that way the user gets to see more direct and more uniform error messages (namely that we couldn't connect to libvirt). Document those connection problems, and a simple

From: "Richard W.M. Jones" <rjones at redhat.com> The option takes values of "virtio-scsi", "virtio-blk" (with the latter being the default). It maps on the convert option with the same name introduced in the previous commits, thus allowing us to alter the order in which the VirtIO block drivers are going to be searched for. This is useful if we want the

From: "Richard W.M. Jones" <rjones at redhat.com> The option takes values of "virtio-scsi", "virtio-blk" (with the latter being the default). It maps on the convert option with the same name introduced in the previous commits, thus allowing us to alter the order in which the VirtIO block drivers are going to be searched for. This is useful if we want the

--- v2v/virt-v2v.pl | 140 ++++++++++++++++++++++++++++++++++++++++--------------- 1 files changed, 102 insertions(+), 38 deletions(-) diff --git a/v2v/virt-v2v.pl b/v2v/virt-v2v.pl index c1a4728..3559738 100755 --- a/v2v/virt-v2v.pl +++ b/v2v/virt-v2v.pl @@ -21,7 +21,6 @@ use strict; use Pod::Usage; use Getopt::Long; -#use Data::Dumper; use File::Spec; use File::stat; @@ -50,16 +49,19

We previously implicitly supported writing to block devices instead of local files, but there were several problems: * Block devices could be deleted, especially if virt-v2v failed during a conversion. * Block devices could be overwritten by a file with the same name, although I believe this is just an observed consequence of the previous point, or at least I was not able to reproduce this

Hi Richard, That didn't resolve the issue. Now I'm getting the following error. Please advice. *[root@kvm16 ~]#* virt-v2v -ic esx://10.16.32.13/?no_verify=1 yardqakvm -o rhev -os 10.16.32.16:/vm-images/export_domain --network rhevm libvirt error code: 42, message: Domain not found: No domain with name 'yardqakvm'

On Thu, Feb 25, 2016 at 08:41:38PM +0300, Roman Kagan wrote: > On Thu, Feb 25, 2016 at 09:54:31AM +0000, Richard W.M. Jones wrote: > > On Wed, Feb 24, 2016 at 05:33:44PM +0300, Roman Kagan wrote: > > > Passing that on the command line makes sense for the copying mode, > > > because in that mode there's no other place where to affect the choices. > > > >

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

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

On Wed, Oct 11, 2017 at 05:17:14PM +0200, Pino Toscano wrote: > On Wednesday, 11 October 2017 15:25:26 CEST Richard W.M. Jones wrote: > > If you accidentally point -i vmx at a disk image, it will try to load > > the whole thing into memory and crash. Catch this narrow case and > > print an error. > > > > However don't fail if ‘file’ is not installed or if we

Create the correct tags for <video> in the libvirtxml, so all the attributes are in a <model> child of <video> instead of <video> itself. Adapt the XML of test-v2v-i-ova to the different expected XML. --- v2v/output_libvirt.ml | 9 +++++---- v2v/test-v2v-i-ova.xml | 4 +++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/v2v/output_libvirt.ml

Hello, I've trying to move a 32bit CentOS 6.4 on VirtualBox to oVirt on Fedora 19 64bit via virt-v2v. The command I'm currently using is: virt-v2v -i libvirtxml -of qcow2 -oa sparse -o rhev -osd xxx.xxx.xxx.xxx:/usr/local/ovirt/exports --network ovirtmgmt /usr1/home/williams/Downloads/OpenAthens/VMs/OpenAthensLARuntime2.2.xml The exciting bit of the XML is: <devices>

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

Extend Modules_list to handle also aliases for input and output modules, and use this to register the existing aliases. --- v2v/input_disk.ml | 2 +- v2v/modules_list.ml | 25 +++++++++++++++++++++---- v2v/modules_list.mli | 8 ++++---- v2v/output_local.ml | 2 +- v2v/output_rhev.ml | 2 +- 5 files changed, 28 insertions(+), 11 deletions(-) diff --git a/v2v/input_disk.ml

We have phony tools for v2v tests, introduced with commit c1af1ba32f126b7be275bcc8cd4ea4e5af27a88e; make use of it also in tests related to v2v outside the v2v directory. --- p2v/test-virt-p2v.sh | 6 +----- tests/regressions/rhbz1232192.sh | 6 +----- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/p2v/test-virt-p2v.sh b/p2v/test-virt-p2v.sh index 8c3731c..540d2fd

Since RHV 3.6.10, the default network name is 'ovirtmgmt' instead of 'rhvm'. This is just a documentation change. --- p2v/virt-p2v.pod | 10 +++++----- v2v/cmdline.ml | 2 +- v2v/virt-v2v.pod | 12 ++++++------ 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/p2v/virt-p2v.pod b/p2v/virt-p2v.pod index ea685be..4a5f587 100644 --- a/p2v/virt-p2v.pod +++