Automated test case tp-libvirt/libvirt rhel.virsh.domfsinfo.positive_tests.no_freezed_fs

I've had a look at this now and the problem is in the qemu-guest-agent indeed (i.e. not in the libvirt side).

The related function build_guest_fsinfo_for_real_device() in the file qga/commands-posix.c starts with this check:

    p = strstr(syspath, "/devices/pci");
    if (!p || sscanf(p + 12, "%*x:%*x/%x:%x:%x.%x%n",
                     pci, pci + 1, pci + 2, pci + 3, &pcilen) < 4) {
        g_debug("only pci device is supported: sysfs path '%s'", syspath);
        return;
    }

That means the fields are only filled in for PCI devices. Since we are using CCW devices on s390x, the information is not gathered by the guest agent.

I'll have a look how this can be fixed...

I had to learn the hard way that libvirt needs some modifications, too.
The function qemuAgentFSInfoToPublic() in src/qemu_driver.c can currently only deal with PCI disks:

   for (i = 0; i < ret->ndevAlias; i++) {
        qemuAgentDiskInfoPtr agentdisk = agent->disks[i];
        virDomainDiskDefPtr diskDef;

        if (!(diskDef = virDomainDiskByAddress(vmdef,
                                               &agentdisk->pci_controller,
                                               agentdisk->bus,
                                               agentdisk->target,
                                               agentdisk->unit)))
            continue;

        ret->devAlias[i] = g_strdup(diskDef->dst);
    }

... i.e. the devAlias (which is shown as the "Target" in "virsh domfsinfo") is currently only set for PCI disks.

Suggested patches for QEMU:

https://lore.kernel.org/qemu-devel/20200720110133.4366-1-thuth@redhat.com/

Patches have now been merged upstream:

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d9fe4f0fea31f0560dc40d3576bc6c48ad97109f
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=43dadc431bacbc5a5baee7e256288a98a3e95ce3
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=23843c129d5e1ca360605e511a43a34faebb47c4

Please, note that the reported Expected result is wrong. The Target column contains as per manpage "unique target names used in  the  domain  XML  (<target dev='name'/>)". I confirmed that on x86_64.

Expected results:

 Mountpoint   Name   Type   Target
------------------------------------
 /            dm-0   xfs    vda
 /boot        vda1   xfs    vda

E2E test failed. Info on https://bugzilla.redhat.com/show_bug.cgi?id=1858771#c8
I'm not sure if QEMU part works as expected so not changing status for now until I know more.

Confirmed with Peter that the passed json reads a pci address while we should expect a ccw address. Setting back to assigned, sorry for inconvenience.

Steps:
1. Set up guest to have
 a. qcow2 boot image in guest with <target dev='vda'/>
 b. qemu-agent channel set up
<channel type='unix'>
   <source mode='bind' path='/var/lib/libvirt/qemu/f16s390x.agent'/>
   <target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>
 c. qemu-guest-agent installed
2. Start guest
3. Send command '{"execute":"guest-get-fsinfo"}'

Actual result:
[
  {
    "return": [
      {
        "name": "vda1",
        "total-bytes": 1063256064,
        "mountpoint": "/boot",
        "disk": [
          {
            "bus-type": "virtio",
            "bus": 0,
            "unit": 0,
            "pci-controller": {
              "bus": -1,
              "slot": -1,
              "domain": -1,
              "function": -1
            },
            "dev": "/dev/vda1",
            "target": 0
          }
        ],
        "used-bytes": 130871296,
        "type": "xfs"
      },
      {
        "name": "dm-0",
        "total-bytes": 3743416320,
        "mountpoint": "/",
        "disk": [
          {
            "bus-type": "virtio",
            "bus": 0,
            "unit": 0,
            "pci-controller": {
              "bus": -1,
              "slot": -1,
              "domain": -1,
              "function": -1
            },
            "dev": "/dev/vda2",
            "target": 0
          }
        ],
        "used-bytes": 1565663232,
        "type": "xfs"
      }
    ]
  }
]

Expected result:
Not sure but it should not be an invalid pci address but most likely a ccw address.

Thomas, based on the libvirt codebase (qemu_agent.c, qemu_driver.c, remote_daemon_dispatch.c, virsh_domain.c, libvirt_domain.c), the response from "execute":"guest-get-fsinfo" on libvirt side is only used in commands (local or remote):

* virsh domfsinfo
* virsh guestinfo

Neither use the pci address info. A possible conclusing is this BZ for the qemu component might not require change for fixing the libvirt output on related BZ:

# virsh guestinfo
user.count          : 0
os.id               : rhel
os.name             : Red Hat Enterprise Linux
os.pretty-name      : Red Hat Enterprise Linux 8.4 Beta (Ootpa)
os.version          : 8.4 (Ootpa)
os.version-id       : 8.4
os.machine          : s390x
os.kernel-release   : 4.18.0-240.10.el8.s390x
os.kernel-version   : #1 SMP Fri Oct 30 03:50:29 EDT 2020
timezone.name       : CST
timezone.offset     : 28800
hostname            : localhost.localdomain
fs.count            : 2
fs.0.name           : dm-0
fs.0.mountpoint     : /
fs.0.fstype         : xfs
fs.0.total-bytes    : 3743416320
fs.0.used-bytes     : 1583079424
fs.0.disk.count     : 1
fs.0.disk.0.device  : /dev/vda2
fs.1.name           : vda1
fs.1.mountpoint     : /boot
fs.1.fstype         : xfs
fs.1.total-bytes    : 1063256064
fs.1.used-bytes     : 130871296
fs.1.disk.count     : 1
fs.1.disk.0.device  : /dev/vda1

I think the QEMU side here is fine. The "pci-controller" section in the JSON is unfortunately mandatory, so it can't be skipped and has to be marked as invalid with these "-1" values (see https://www.qemu.org/docs/master/interop/qemu-ga-ref.html#index-GuestDiskAddress ). And CCW addresses are not possible there yet either. But you're right, the output on the libvirt side does not match what you'd expect from other architectures, so BZ 1858771 needs to be reworked...

The QEMU part is fine, the remaining problem is on the libvirt side indeed. Moving this part here back to ON_QA ... and will post a patch for libvirt as soon as possible later.

After discussing the libvirt side of this problem a little bit further, it seems like there might some additional work to be done on the QEMU side, too. After all we likely need to send the CCW address, too. Moving the state back to ASSIGNED.

I've now posted the patch upstream that should provide the necessary information from the QEMU guest agent side:
https://lore.kernel.org/qemu-devel/20201125105417.380317-1-thuth@redhat.com/

Sanity tested with
qemu-guest-agent-5.2.0-3.module+el8.4.0+9499+42e58f08.s390x
qemu-kvm-5.2.0-3.module+el8.4.0+9499+42e58f08.s390x
libvirt-7.0.0-1.module+el8.4.0+9464+3e71831a.s390x

Run virsh domfsinfo vm

Result:
A)
# virsh domfsinfo vm
 Mountpoint   Name   Type   Target
------------------------------------
 /            dm-0   xfs    vda
 /boot        vda1   xfs    vda

B)
QEMU request from libvirt log:
[
  {
    "return": [
      {
        "name": "vda1",
        "total-bytes": 1063256064,
        "mountpoint": "/boot",
        "disk": [
          {
            "ccw-address": {
              "cssid": 0,
              "ssid": 0,
              "subchno": 2,
              "devno": 0
            },
            "bus-type": "virtio",
            "bus": 0,
            "unit": 0,
            "pci-controller": {
              "bus": -1,
              "slot": -1,
              "domain": -1,
              "function": -1
            },
            "dev": "/dev/vda1",
            "target": 0
          }
        ],
        "used-bytes": 132022272,
        "type": "xfs"
      },
      {
        "name": "dm-0",
        "total-bytes": 3743416320,
        "mountpoint": "/",
        "disk": [
          {
            "ccw-address": {
              "cssid": 0,
              "ssid": 0,
              "subchno": 2,
              "devno": 0
            },
            "bus-type": "virtio",
            "bus": 0,
            "unit": 0,
            "pci-controller": {
              "bus": -1,
              "slot": -1,
              "domain": -1,
              "function": -1
            },
            "dev": "/dev/vda2",
            "target": 0
          }
        ],
        "used-bytes": 1658707968,
        "type": "xfs"
      }
    ]
  }
]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:2098