7:34 a.m.
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
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
Notes:
v2:
- rewrite using the language suggested by Rich
context:-U12
docs/virt-v2v.pod | 23 +++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/docs/virt-v2v.pod b/docs/virt-v2v.pod
index 4d2f241ad723..ac15108ae332 100644
--- a/docs/virt-v2v.pod
+++ b/docs/virt-v2v.pod
@@ -250,24 +250,26 @@ metadata. virt-v2v tries to guess the best default metadata. This
is
usually adequate but you can get finer control (eg. of memory and
vCPUs) by using I<-i libvirtxml> instead. Only guests that use a single
disk can be imported this way.
=item B<-i> B<libvirt>
Set the input method to I<libvirt>. This is the default.
In this mode you have to specify a libvirt guest name or UUID on the
command line. You may also specify a libvirt connection URI (see
I<-ic>).
+See L</Starting the libvirt system instance> below.
+
=item B<-i> B<libvirtxml>
Set the input method to I<libvirtxml>.
In this mode you have to pass a libvirt XML file on the command line.
This file is read in order to get metadata about the source guest
(such as its name, amount of memory), and also to locate the input
disks. See L</Minimal XML for -i libvirtxml option> below.
=item B<-i> B<local>
This is the same as I<-i disk>.
@@ -461,25 +463,26 @@ and guest metadata is created in the associated YAML file:
/dir/name.yaml
where C<name> is the guest name.
=item B<-o> B<libvirt>
Set the output method to I<libvirt>. This is the default.
In this mode, the converted guest is created as a libvirt guest. You
may also specify a libvirt connection URI (see I<-oc>).
-See L<virt-v2v-output-local(1)>.
+See L</Starting the libvirt system instance> below, and
+L<virt-v2v-output-local(1)>.
=item B<-o> B<local>
Set the output method to I<local>.
In this mode, the converted guest is written to a local directory
specified by I<-os /dir> (the directory must exist). The converted
guest’s disks are written as:
/dir/name-sda
/dir/name-sdb
[etc]
@@ -1373,24 +1376,26 @@ manually change ownership after virt-v2v has finished.
=item Writing to libvirt
When using I<-o libvirt>, you may need to run virt-v2v as root so that
it can write to the libvirt system instance (ie. C<qemu:///system>)
and to the default location for disk images (usually
F</var/lib/libvirt/images>).
You can avoid this by setting up libvirt connection authentication,
see L<http://libvirt.org/auth.html>;. Alternatively, use
I<-oc qemu:///session>, which will write to your per-user libvirt
instance.
+See also L</Starting the libvirt system instance>.
+
=item Writing to Openstack
Because of how Cinder volumes are presented as F</dev> block devices,
using I<-o openstack> normally requires that virt-v2v is run as root.
=item Writing to Glance
This does I<not> need root (in fact it probably won’t work), but may
require either a special user and/or for you to source a script that
sets authentication environment variables. Consult the Glance
documentation.
@@ -1521,24 +1526,40 @@ displayed to the user.
The calling program should treat messages sent to stderr as error
messages. In addition, virt-v2v exits with a non-zero status
code if there was a fatal error.
=back
Virt-v2v E<le> 0.9.1 did not support the I<--machine-readable>
option at all. The option was added when virt-v2v was rewritten in 2014.
It is possible to specify a format string for controlling the output;
see L<guestfs(3)/ADVANCED MACHINE READABLE OUTPUT>.
+=head2 Starting the libvirt system instance
+
+ Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or
directory
+ Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': Connection
refused
+
+If you have just installed libvirt and virt-v2v, then you may see the
+errors above. This is caused by libvirt daemons that provide various
+services not running straight after installation. (This may depend on
+your distribution and vendor presets).
+
+To fix this on systemd-based distributions, do:
+
+ systemctl isolate multi-user.target
+
+See also L<https://bugzilla.redhat.com/2182024>;.
+
=head1 FILES
=over 4
=item F</usr/share/virtio-win>
(Optional)
If this directory is present, then virtio drivers for Windows guests
will be found from this directory and installed in the guest during
conversion.