Bug 1705520

Rather than adding them to bulk stats, I've proposed a new API for returning guest information that doesn't change frequently and is modeled on the bulk stats API. Patch series here: https://www.redhat.com/archives/libvir-list/2019-August/msg01089.html

virDomainGetGuestInfo() patches were merged upstream.

In virsh, this information is returned in the new 'guestinfo' command.

*** Bug 1704779 has been marked as a duplicate of this bug. ***

Verify this bug with:
libvirt-6.0.0-2.module+el8.2.0+5513+34927b6c.x86_64
qemu-guest-agent-4.2.0-8.module+el8.2.0+5607+dc756904.x86_64

A) positive scenarios:
1) prepare one rhel and one linux guest
# virsh list --all
 Id   Name                       State
-------------------------------------------
 2    rhel8.2                    running
 3    win10                      running

2)check the filesystem info in guest
[root@newhost ~]# df 
Filesystem            1K-blocks    Used Available Use% Mounted on
devtmpfs                 401636       0    401636   0% /dev
tmpfs                    419024       0    419024   0% /dev/shm
tmpfs                    419024   11048    407976   3% /run
tmpfs                    419024       0    419024   0% /sys/fs/cgroup
/dev/mapper/rhel-root   8374272 2019824   6354448  25% /
/dev/vda1               1038336  169052    869284  17% /boot
tmpfs                     83804       0     83804   0% /run/user/0

3) check the filesystem info via guest agent
# virsh guestinfo rhel8.2 --filesystem 
fs.count            : 2
fs.0.name           : dm-0
fs.0.mountpoint     : /
fs.0.fstype         : xfs
fs.0.total-bytes    : 8575254528
fs.0.used-bytes     : 2068299776
fs.0.disk.count     : 1
fs.0.disk.0.alias   : vda
fs.0.disk.0.serial  : dan123virtio
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     : 173109248
fs.1.disk.count     : 1
fs.1.disk.0.alias   : vda
fs.1.disk.0.serial  : dan123virtio
fs.1.disk.0.device  : /dev/vda1

4)hotplug a disk to guest, mount the disk, then check the filesystem info in guest
[root@newhost ~]# df 
Filesystem            1K-blocks    Used Available Use% Mounted on
devtmpfs                 401636       0    401636   0% /dev
tmpfs                    419024       0    419024   0% /dev/shm
tmpfs                    419024   11060    407964   3% /run
tmpfs                    419024       0    419024   0% /sys/fs/cgroup
/dev/mapper/rhel-root   8374272 2019828   6354444  25% /
/dev/vda1               1038336  169052    869284  17% /boot
tmpfs                     83804       0     83804   0% /run/user/0
/dev/vdb1                486610    2318    454648   1% /mnt

5) check the filesystem info via guest agent
# virsh guestinfo rhel8.2 --filesystem 
fs.count            : 3
fs.0.name           : dm-0
fs.0.mountpoint     : /
fs.0.fstype         : xfs
fs.0.total-bytes    : 8575254528
fs.0.used-bytes     : 2068303872
fs.0.disk.count     : 1
fs.0.disk.0.alias   : vda
fs.0.disk.0.serial  : dan123virtio
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     : 173109248
fs.1.disk.count     : 1
fs.1.disk.0.alias   : vda
fs.1.disk.0.serial  : dan123virtio
fs.1.disk.0.device  : /dev/vda1
fs.2.name           : vdb1
fs.2.mountpoint     : /mnt
fs.2.fstype         : ext4
fs.2.total-bytes    : 467933184
fs.2.used-bytes     : 2373632
fs.2.disk.count     : 1
fs.2.disk.0.alias   : vdb
fs.2.disk.0.serial  : 1234567890
fs.2.disk.0.device  : /dev/vdb1

8) umount the vdb1 disk, check the filesystem, vdb related info disappeared

9) check the filesystem info of windows guest
fs.count            : 3
fs.0.name           : \\?\Volume{41bd8752-0000-0000-0000-100000000000}\
fs.0.mountpoint     : System Reserved
fs.0.fstype         : NTFS
fs.0.disk.count     : 1
fs.0.disk.0.serial  : QM00001
fs.0.disk.0.device  : \\.\PhysicalDrive0
fs.1.name           : \\?\Volume{41bd8752-0000-0000-0000-402400000000}\
fs.1.mountpoint     : C:\
fs.1.fstype         : NTFS
fs.1.total-bytes    : 15496900608
fs.1.used-bytes     : 14383763456
fs.1.disk.count     : 1
fs.1.disk.0.serial  : QM00001
fs.1.disk.0.device  : \\.\PhysicalDrive0
fs.2.name           : \\?\Volume{b31cfef3-2b63-11ea-9fe8-806e6f6e6963}\
fs.2.mountpoint     : D:\
fs.2.fstype         : CDFS
fs.2.total-bytes    : 268810240
fs.2.used-bytes     : 268810240
fs.2.disk.count     : 1
fs.2.disk.0.device  : \\?\Volume{b31cfef3-2b63-11ea-9fe8-806e6f6e6963}

10)unplug sdb and restart win10 
# virsh detach-disk win10 sdb --config 
Disk detached successfully

11)check the filesystem via guest agent again
# virsh guestinfo win10 --filesystem 
fs.count            : 2
fs.0.name           : \\?\Volume{41bd8752-0000-0000-0000-100000000000}\
fs.0.mountpoint     : System Reserved
fs.0.fstype         : NTFS
fs.0.disk.count     : 1
fs.0.disk.0.serial  : QM00001
fs.0.disk.0.device  : \\.\PhysicalDrive0
fs.1.name           : \\?\Volume{41bd8752-0000-0000-0000-402400000000}\
fs.1.mountpoint     : C:\
fs.1.fstype         : NTFS
fs.1.total-bytes    : 15496900608
fs.1.used-bytes     : 14320214016
fs.1.disk.count     : 1
fs.1.disk.0.serial  : QM00001
fs.1.disk.0.device  : \\.\PhysicalDrive0

Negative Scenarios:
1) check filesystem info under read-only mode
# virsh -r guestinfo win10 --filesystem 
error: operation forbidden: read only access prevents virDomainGetGuestInfo

2) check filesystem info when guest agent service is stopped
# virsh guestinfo win10 --filesystem 
error: Guest agent is not responding: QEMU guest agent is not connected

3) check filesystem info when guest agent is not configured
# virsh dumpxml rhel8.2 |grep agent
(no output)
# virsh guestinfo rhel8.2 --filesystem 
error: argument unsupported: QEMU guest agent is not configured

As the testing match with expected results, mark the bug as verified

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, 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-2020:2017