[Libguestfs] virt-df stuck at supermin: [...] waiting for /sys/block/sdb/dev to appear

[Richard W.M. Jones]

On Tue, Nov 20, 2018 at 03:15:54PM +0200, Peter Dimitrov wrote:
> This problem occurs on certain machines but I can't tell why and how
> exactly to fix it.
> 
> The message suggests a problem with kernel modules, but they all seem to
> load successfully, including many virtio modules.

These are quite old versions of kernel/qemu/libguestfs/supermin so I
can only really offer general advice.  You are right that the problem
is caused because the appliance kernel does not see any virtio-scsi
disks.  That can be for a variety of reasons such as:

 - The virtio drivers in the appliance are not loaded or not working
   for some reason.

 - qemu isn't presenting virtio devices to the guest.

>From the trace:

libguestfs: libvirt XML:\n [...] <devices>
    <controller type="scsi" index="0" model="virtio-scsi"/>
    <disk device="disk" type="file">
      <source file="/tmp/libguestfsdTUUkY/overlay1">
        <seclabel model="selinux" relabel="no"/>
      </source>
      <target dev="sda" bus="scsi"/>
      <driver name="qemu" type="qcow2" cache="unsafe"/>
      <address type="drive" controller="0" bus="0" target="0" unit="0"/>
    </disk>
    <disk type="file" device="disk">
      <source file="/tmp/libguestfsdTUUkY/overlay2"/>
      <target dev="sdb" bus="scsi"/>
      <driver name="qemu" type="qcow2" cache="unsafe"/>
      <address type="drive" controller="0" bus="0" target="1" unit="0"/>
      <shareable/>
    </disk>

This ought to cause libvirt to tell qemu to present virtio-scsi
devices.  You can check if they are actually present on the qemu
command line by looking for /var/log/libvirt/qemu/guestfs-XXX.log

supermin: internal insmod crc32c-intel.ko
supermin: internal insmod virtio.ko
supermin: internal insmod virtio_ring.ko
supermin: internal insmod virtio_blk.ko
supermin: internal insmod virtio_console.ko
supermin: internal insmod virtio_net.ko
supermin: internal insmod virtio_scsi.ko

The Virtio SCSI driver is getting loaded.

supermin: internal insmod virtio_balloon.ko
supermin: internal insmod virtio_input.ko
supermin: internal insmod virtio_mmio.ko
supermin: internal insmod virtio_pci.ko
[    0.289514] virtio-pci 0000:00:02.0: PCI->APIC IRQ transform: INT A -> IRQ 10
[    0.289888] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver
[    0.290355] virtio-pci 0000:00:03.0: PCI->APIC IRQ transform: INT A -> IRQ 11
[    0.290768] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
[    0.291008] virtio-pci 0000:00:04.0: PCI->APIC IRQ transform: INT A -> IRQ 11
[    0.291392] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver

This indicates that the Virtio PCI transport module is being loaded.
The "virtio_pci: leaving for legacy driver" message is worrying.

I think what's happening here is your appliance kernel only has
drivers for virtio 1.0 ("virtio modern") but your qemu is presenting
virtio legacy drivers.  There's a kernel config option to enable
virtio legacy (VIRTIO_PCI_LEGACY) which you should probably try first.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top