[Libguestfs] [PATCH 1/4] v2v: Detect conversions where the source disk has zero size (RHBZ#1283588).

[Richard W.M. Jones]

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