+++ This bug was initially created as a clone of Bug #1859494 +++ In RHEL 7 and below, ovirt-guest-agent reported logical names also of disks with no file-system mounted. We need qemu-guest-agent to do the same on RHEL 8, otherwise RHV users that upgrade their guests to RHEL 8 would miss that information.
Initial version posted upstream: https://patchew.org/Libvirt/20201120180948.203254-1-marcandre.lureau@redhat.com/
Pushed upstream: 172b830435 virsh: add --disk informations to guestinfo command 0cb2d9f05d qemu_driver: report guest disk informations 05a75ca2ce domain: add disk informations to virDomainGetGuestInfo 8401a586a2 qemu_agent: add qemuAgentGetDisks 3169db81f6 qemu: use virJSONValueObjectGetStringArray b3dad96972 util: json: add virJSONValueObjectGetStringArray convenience c6fcb75f77 qemu_agent: factor out qemuAgentGetDiskAddress f534eae275 qemu_agent: export qemuAgentDiskAddressFree & add g_auto v6.10.0-10-g172b830435 Although, this patch is somewhat important: https://www.redhat.com/archives/libvir-list/2020-December/msg00020.html Hence, I'm not moving to POST just yet.
Some further API fixes were required for consistency https://www.redhat.com/archives/libvir-list/2020-December/msg00146.html
Merged patch from comment 2: b46ec55d53 qemuDomainGetGuestInfo: Exit early if getting info fails v6.10.0-43-gb46ec55d53
Patch from comment 3 is not merged too: d4745bb909 src: use singular form instead of plural, for guest disk info v6.10.0-69-gd4745bb909
I believe this bug should be moved to RHEL-AV. The original qemu-guest-agent bug makes sense in RHEL since it's a guest change and we want that in RHEL (non-AV), but this libvirt part is on the host side, which should be RHEL-AV for RHV.
(In reply to Jiri Denemark from comment #6) > I believe this bug should be moved to RHEL-AV. The original qemu-guest-agent > bug makes sense in RHEL since it's a guest change and we want that in RHEL > (non-AV), but this libvirt part is on the host side, which should be RHEL-AV > for RHV. In that case, upstream work is done and this can go to POST then.
(In reply to Jiri Denemark from comment #6) > I believe this bug should be moved to RHEL-AV. The original qemu-guest-agent > bug makes sense in RHEL since it's a guest change and we want that in RHEL > (non-AV), but this libvirt part is on the host side, which should be RHEL-AV > for RHV. I believe you are correct. Arik, that's also what you expected for ovirt support (bug 1836661)?
(In reply to Marc-Andre Lureau from comment #8) > (In reply to Jiri Denemark from comment #6) > > I believe this bug should be moved to RHEL-AV. The original qemu-guest-agent > > bug makes sense in RHEL since it's a guest change and we want that in RHEL > > (non-AV), but this libvirt part is on the host side, which should be RHEL-AV > > for RHV. > > I believe you are correct. > > Arik, that's also what you expected for ovirt support (bug 1836661)? Yes, that's correct.
Test steps: https://www.redhat.com/archives/libvir-list/2020-December/msg00010.html
Tested this bug with: libvirt-6.10.0-1.fc34.x86_64 qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64 qemu-guest-agent-5.2.0-2.module+el8.4.0+9186+ec44380f.x86_64 1. prepare a guest with guest agent device virsh domtime pc Time: 1609318675 2. create an unmounted iscsi disk in guest # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1G 0 disk /mnt vda 252:0 0 10G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 9G 0 part ├─rhel-root 253:0 0 8G 0 lvm / └─rhel-swap 253:1 0 1G 0 lvm [SWAP] 3. report filesystem information virsh guestinfo pc --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 : 1748971520 fs.0.disk.count : 1 fs.0.disk.0.alias : vda 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 : 183119872 fs.1.disk.count : 1 fs.1.disk.0.alias : vda fs.1.disk.0.device : /dev/vda1 4. report disk information virsh guestinfo pc --disk disk.count : 6 disk.0.name : /dev/vda1 disk.0.partition : yes disk.0.dependency.count: 1 disk.0.dependency.0.name: /dev/vda disk.1.name : /dev/vda2 disk.1.partition : yes disk.1.dependency.count: 1 disk.1.dependency.0.name: /dev/vda disk.2.name : /dev/vda disk.2.partition : no disk.2.alias : vda disk.3.name : /dev/sda <== unmounted disk disk.3.partition : no disk.4.name : /dev/dm-0 disk.4.partition : no disk.4.dependency.count: 1 disk.4.dependency.0.name: /dev/vda2 disk.4.guest_alias : rhel-root disk.5.name : /dev/dm-1 disk.5.partition : no disk.5.dependency.count: 1 disk.5.dependency.0.name: /dev/vda2 disk.5.guest_alias : rhel-swap 5. construct filesystem on sda1 and mount the disk virsh guestinfo --disk pc disk.count : 7 disk.0.name : /dev/vda1 disk.0.partition : yes disk.0.dependency.count: 1 disk.0.dependency.0.name: /dev/vda disk.1.name : /dev/vda2 disk.1.partition : yes disk.1.dependency.count: 1 disk.1.dependency.0.name: /dev/vda disk.2.name : /dev/vda disk.2.partition : no disk.2.alias : vda disk.3.name : /dev/sda1 disk.3.partition : yes disk.3.dependency.count: 1 disk.3.dependency.0.name: /dev/sda disk.4.name : /dev/sda disk.4.partition : no disk.5.name : /dev/dm-0 disk.5.partition : no disk.5.dependency.count: 1 disk.5.dependency.0.name: /dev/vda2 disk.5.guest_alias : rhel-root disk.6.name : /dev/dm-1 disk.6.partition : no disk.6.dependency.count: 1 disk.6.dependency.0.name: /dev/vda2 disk.6.guest_alias : rhel-swap 6. check the filesystem info virsh guestinfo --filesystem pc fs.count : 3 fs.0.name : dm-0 fs.0.mountpoint : / fs.0.fstype : xfs fs.0.total-bytes : 8575254528 fs.0.used-bytes : 1754783744 fs.0.disk.count : 1 fs.0.disk.0.alias : vda 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 : 183119872 fs.1.disk.count : 1 fs.1.disk.0.alias : vda fs.1.disk.0.device : /dev/vda1 fs.2.name : sda1 fs.2.mountpoint : /mnt fs.2.fstype : xfs fs.2.total-bytes : 522878976 fs.2.used-bytes : 30318592 fs.2.disk.count : 1 fs.2.disk.0.serial : 360014054d41384d5d67471dbade68599 fs.2.disk.0.device : /dev/sda1
Tested this bug with: libvirt-daemon-7.0.0-2.module+el8.4.0+9520+ef609c5f.x86_64 qemu-guest-agent-5.2.0-3.module+el8.4.0+9499+42e58f08.x86_64 1.prepare a guest with guest agent device virsh domtime avocado-vt-vm1 Time: 1609318675 2. check the disk of guest # virsh guestinfo avocado-vt-vm1 --disk disk.count : 5 disk.0.name : /dev/vda1 disk.0.partition : yes disk.0.dependency.count: 1 disk.0.dependency.0.name: /dev/vda disk.1.name : /dev/vda2 disk.1.partition : yes disk.1.dependency.count: 1 disk.1.dependency.0.name: /dev/vda disk.2.name : /dev/vda disk.2.partition : no disk.2.alias : vda disk.3.name : /dev/dm-0 disk.3.partition : no disk.3.dependency.count: 1 disk.3.dependency.0.name: /dev/vda2 disk.3.guest_alias : rhel-root disk.4.name : /dev/dm-1 disk.4.partition : no disk.4.dependency.count: 1 disk.4.dependency.0.name: /dev/vda2 disk.4.guest_alias : rhel-swap 3. attach a disk to guest # virsh attach-disk avocado-vt-vm1 /var/lib/libvirt/images/test.img vdb Disk attached successfully 4. check disk of guest # virsh guestinfo avocado-vt-vm1 --disk disk.count : 6 disk.0.name : /dev/vda1 disk.0.partition : yes disk.0.dependency.count: 1 disk.0.dependency.0.name: /dev/vda disk.1.name : /dev/vda2 disk.1.partition : yes disk.1.dependency.count: 1 disk.1.dependency.0.name: /dev/vda disk.2.name : /dev/vda disk.2.partition : no disk.2.alias : vda disk.3.name : /dev/dm-0 disk.3.partition : no disk.3.dependency.count: 1 disk.3.dependency.0.name: /dev/vda2 disk.3.guest_alias : rhel-root disk.4.name : /dev/vdb <== (new disk here) disk.4.partition : no disk.4.alias : vdb disk.5.name : /dev/dm-1 disk.5.partition : no disk.5.dependency.count: 1 disk.5.dependency.0.name: /dev/vda2 disk.5.guest_alias : rhel-swap Logical names also of disks with no file-system mounted can be shown now, mark the bug as verified.
Forget to mention about the feature supporting status for windows guest, change the bug status back to ON_QA status
Will track the feature supporting status for windows guest in Bug #1919535, mark the bug as verified.
The way this was implemented in libvirt makes it problematic to use from oVirt. Is there any reason why the address and especially serial number is not reported? The fact that only a disk name is reported means we have to construct a mapping between names and serial numbers AND ensure this has not changed during the calls to qemu-ga. Otherwise we risk reporting wrong guest disk names and users can run into serious troubles. All in all this has serious drawbacks compared to the qemu-ga API. Can we enhance the libvirt API?
(In reply to Tomáš Golembiovský from comment #17) > The way this was implemented in libvirt makes it problematic to use from > oVirt. Is there any reason why the address and especially serial number is > not reported? > > The fact that only a disk name is reported means we have to construct a > mapping between names and serial numbers AND ensure this has not changed > during the calls to qemu-ga. Otherwise we risk reporting wrong guest disk > names and users can run into serious troubles. > > All in all this has serious drawbacks compared to the qemu-ga API. Can we > enhance the libvirt API? Tomas, libvirt fetches addresses internally and uses them to find corresponding disk <target/> in the domain XML. However, it seems that serial is fetched but unused. That should be fairly easy to expose. But I'm not so sure about the address field - I mean, disks can be on various buses and each uses different addressing scheme. What format would help you for addresses?
I've posted a patch that exposes disk serial here: https://listman.redhat.com/archives/libvir-list/2021-April/msg00552.html
(In reply to Michal Privoznik from comment #19) > I've posted a patch that exposes disk serial here: > > https://listman.redhat.com/archives/libvir-list/2021-April/msg00552.html And remember to mention that in virsh manpage
At the moment we only need the serial number and we're not interested in the address as such (bus/slot/etc.). This patch is good enough and greatly improves the usability. Thank you!
v2: https://listman.redhat.com/archives/libvir-list/2021-April/msg00560.html Tomas, do you want this tracked in a separate bug? This one is in VERIFIED and I'd like to keep it that way.
Sure, whatever you prefer.
Okay, new bug it is then.
New bug created: bug 1949486.
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