1:37 p.m.
If you try to convert a guest that has a zero-sized disk, it
will currently fail in a rather strange way. Usually you will
see errors in the debug output:
[ 0.562714] sd 2:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 0.563884] sd 2:0:0:0: [sda] Sense Key : Not Ready [current]
[ 0.564587] sd 2:0:0:0: [sda] Add. Sense: Logical unit not ready, manual intervention
required
followed by virt-v2v failing with:
libguestfs: trace: v2v: inspect_os = []
virt-v2v: error: inspection could not detect the source guest (or physical
machine).
Additionally, because of a problem with the ssh driver in qemu (or
perhaps, with sftp-server on the remote side) it is not possible to
use the ssh driver to open a block device path on the remote server.
The drive will appear as zero-sized, triggering the above error.
Therefore detect this situation, and emit an error (see below). Also
add a section to the manual describing the workaround required for
converting RHEL 5 Xen guests which are located on block devices.
virt-v2v: error: guest disk sda appears to be zero bytes in size.
There could be several reasons for this:
Check that the guest doesn't really have a zero-sized disk. virt-v2v
cannot convert such a guest.
If you are converting a guest from an ssh source and the guest has a disk
on a block device (eg. on a host partition or host LVM LV), then
conversions of this type are not supported. See "XEN OR SSH CONVERSIONS
FROM BLOCK DEVICES" in the virt-v2v(1) manual for a workaround.
---
v2v/v2v.ml | 7 ++++++
v2v/virt-v2v.pod | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+)
diff --git a/v2v/v2v.ml b/v2v/v2v.ml
index 4b04834..d633601 100644
--- a/v2v/v2v.ml
+++ b/v2v/v2v.ml
@@ -228,6 +228,13 @@ and create_overlays src_disks =
let vsize = (open_guestfs ())#disk_virtual_size overlay_file in
+ (* If the virtual size is 0, then something went badly wrong.
+ * It could be RHBZ#1283588 or some other problem with qemu.
+ *)
+ if vsize = 0L then
+ error (f_"guest disk %s appears to be zero bytes in size.\n\nThere could be
several reasons for this:\n\nCheck that the guest doesn't really have a zero-sized
disk. virt-v2v cannot convert such a guest.\n\nIf you are converting a guest from an ssh
source and the guest has a disk on a block device (eg. on a host partition or host LVM
LV), then conversions of this type are not supported. See \"XEN OR SSH CONVERSIONS
FROM BLOCK DEVICES\" in the virt-v2v(1) manual for a workaround.")
+ sd;
+
{ ov_overlay_file = overlay_file; ov_sd = sd;
ov_virtual_size = vsize; ov_source = source }
) src_disks
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index 2e83168..0b7be7d 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -1226,6 +1226,10 @@ B<If the above commands do not work, then virt-v2v is not going
to
work either>. Fix your libvirt configuration or the remote server
before continuing.
+B<If the guest disks are located on a host block device>, then the
+conversion will fail. See L</XEN OR SSH CONVERSIONS FROM BLOCK DEVICES>
+below for a workaround.
+
=head2 XEN: IMPORTING A GUEST
To import a particular guest from a Xen server, do:
@@ -1241,6 +1245,78 @@ In this case the output flags are set to write the converted guest
to
a temporary directory as this is just an example, but you can also
write to libvirt or any other supported target.
+=head2 XEN OR SSH CONVERSIONS FROM BLOCK DEVICES
+
+It is currently not possible to convert a Xen guest (or any guest
+located remotely over ssh) if that guest's disks are located on host
+block devices.
+
+To tell if a Xen guest uses host block devices, look at the guest XML.
+You will see:
+
+ <disk type='block' device='disk'>
+ ...
+ <source dev='/dev/VG/guest'/>
+
+where C<type='block'>, C<source dev=> and C</dev/...> are all
+indications that the disk is located on a host block device.
+
+This happens because the qemu ssh block driver that we use to access
+remote disks uses the ssh sftp protocol, and this protocol cannot
+correctly detect the size of host block devices.
+
+The workaround is to copy the guest over to the conversion server.
+You will need sufficient space on the conversion server to store a
+full copy of the guest.
+
+=over 4
+
+=item 1.
+
+From the conversion host, dump the guest XML to a local file:
+
+ virsh -c xen+ssh://root@xen.example.com dumpxml guest > guest.xml
+
+=item 2.
+
+From the conversion host, copy the guest disk(s) over. You may need
+to read the C<E<lt>diskE<gt>> sections from the guest XML to find the
+names of the guest disks.
+
+ ssh root(a)xen.example.com 'dd if=/dev/VG/guest' | dd conv=sparse of=guest-disk1
+
+Notice C<conv=sparse> which adds sparseness, so the copied disk will
+use as little space as possible.
+
+=item 3.
+
+Edit the guest XML file, replacing C<E<lt>diskE<gt>> section(s) that
+refer to the remote disks with references to the local copies.
+
+Three changes have to be made. Firstly in:
+
+ <disk type='block' device='disk'>
+
+the C<type> must be changed to C<file>:
+
+ <disk type='file' device='disk'>
+
+The last two changes are in the C<E<lt>sourceE<gt>> line where:
+
+ <source dev='/dev/VG/guest'/>
+
+C<source dev=> becomes C<source file=> pointing at the local file:
+
+ <source file='guest-disk1'/>
+
+=item 4.
+
+Convert the guest using C<virt-v2v -i libvirtxml> mode like this:
+
+ virt-v2v -i libvirtxml guest.xml [-o options as usual ...]
+
+=back
+
=head1 OUTPUT TO LIBVIRT
The I<-o libvirt> option lets you upload the converted guest to
--
2.5.0