Bug 1858771
| Summary: | virsh domfsinfo doesn't return disk info on s390x | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Thomas Huth <thuth> |
| Component: | libvirt | Assignee: | Thomas Huth <thuth> |
| Status: | CLOSED ERRATA | QA Contact: | smitterl |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.1 | CC: | dzheng, jdenemar, jsuchane, juzhang, mjenner, mprivozn, ngu, qzhang, rbalakri, smitterl, thuth, virt-maint, virt-qe-z |
| Target Milestone: | beta | Keywords: | Automation, Patch, Triaged, Upstream |
| Target Release: | 8.4 | ||
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-7.0.0-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1755075 | Environment: | |
| Last Closed: | 2021-05-25 06:42:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | 7.0.0 |
| Embargoed: | |||
| Bug Depends On: | 1755075 | ||
| Bug Blocks: | |||
|
Comment 1
Thomas Huth
2020-07-20 11:14:40 UTC
Patch has been accepted upstream: commit f8333b3b0a7fdbc1f18ed501c043ac7618b86a16 "qemu: Fix domfsinfo for non-PCI device information from guest agent" Please, note that the reported Expected result from https://bugzilla.redhat.com/show_bug.cgi?id=1755075 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 Could not be verified with:
qemu-guest-agent-4.2.0-35.module+el8.4.0+8453+f5da6c50.s390x
qemu-kvm-4.2.0-35.module+el8.4.0+8453+f5da6c50.s390x
libvirt-6.0.0-29.module+el8.4.0+8389+a260c754.s390x
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. virsh domfsinfo
Actual result:
Mountpoint Name Type Target
---------------------------------------
/ dm-0 xfs /dev/vda2
/boot vda1 xfs /dev/vda1
Expected result:
Mountpoint Name Type Target
------------------------------------
/ dm-0 xfs vda
/boot vda1 xfs vda
Notes:
The json returned by qemu is almost identical when comparing x86_64 and s390x:
+------------------------------------+------------------------------------+
| s390x | x86_64 |
+------------------------------------+------------------------------------+
| [ | [ |
| { | { |
| "return": [ | "return": [ |
| { | { |
| "name": "vda1", | "name": "vda1", |
| "total-bytes": 1063256064, | "total-bytes": 1063256064, |
| "mountpoint": "/boot", | "mountpoint": "/boot", |
| "disk": [ | "disk": [ |
| { | { |
| "bus-type": "virtio", | "bus-type": "virtio", |
| "bus": 0, | "bus": 0, |
| "unit": 0, | "unit": 0, |
| "pci-controller": { | "pci-controller": { |
| "bus": -1, | "bus": 4, |
| "slot": -1, | "slot": 0, |
| "domain": -1, | "domain": 0, |
| "function": -1 | "function": 0 |
| }, | }, |
| "dev": "/dev/vda1", | "dev": "/dev/vda1", |
| "target": 0 | "target": 0 |
| } | } |
| ], | ], |
| "used-bytes": 130871296, | "used-bytes": 184553472, |
| "type": "xfs" | "type": "xfs" |
| }, | }, |
| { | { |
| "name": "dm-0", | "name": "dm-0", |
| "total-bytes": 3743416320, | "total-bytes": 8575254528, |
| "mountpoint": "/", | "mountpoint": "/", |
| "disk": [ | "disk": [ |
| { | { |
| "bus-type": "virtio", | "bus-type": "virtio", |
| "bus": 0, | "bus": 0, |
| "unit": 0, | "unit": 0, |
| "pci-controller": { | "pci-controller": { |
| "bus": -1, | "bus": 4, |
| "slot": -1, | "slot": 0, |
| "domain": -1, | "domain": 0, |
| "function": -1 | "function": 0 |
| }, | }, |
| "dev": "/dev/vda2", | "dev": "/dev/vda2", |
| "target": 0 | "target": 0 |
| } | } |
| ], | ], |
| "used-bytes": 1565663232, | "used-bytes": 1666441216, |
| "type": "xfs" | "type": "xfs" |
| } | } |
| ] | ] |
| } | } |
| ] | ] |
+------------------------------------+------------------------------------+
Ok, looks like my understanding of this feature was just simply wrong: https://www.redhat.com/archives/libvir-list/2020-November/msg00680.html I'll check whether it can be solved in another way on s390x... Next try of solving this problem (this time hopefully for real): https://www.redhat.com/archives/libvir-list/2020-November/msg01455.html Merged upstream: bf63f6549a domain_conf: Allow to look up scsi disks when controller uses a CCW address 5db43b5a76 domain_conf: Allow to look up virtio-block devices by their CCW address f5c8cf9e0e qemu: agent: Store CCW address in qemuAgentDiskInfo if provided by the guest v6.10.0-266-g03975775cf but I've posted a small cleanup patch: https://www.redhat.com/archives/libvir-list/2021-January/msg00014.html which would be nice to merge too. Merged upstream: 1165467940 qemu: Drop has_ccw_address from _qemuAgentDiskAddress v6.10.0-267-g1165467940 Forgot to set Upstream keyword with the previous comment (patches are merged upstream). Verified 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 # avocado run --vt-type libvirt --vt-connect-uri qemu:///system --vt-machine-type s390-virtio virsh.domfsinfo.positive_tests.no_freezed_fs JOB ID : 90156e65a7772a27732ae0fd3cfa3bfc644a9ba8 JOB LOG : /root/avocado/job-results/job-2021-01-19T10.27-90156e6/job.log (1/1) type_specific.io-github-autotest-libvirt.virsh.domfsinfo.positive_tests.no_freezed_fs: PASS (59.80 s) RESULTS : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 60.28 s 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 |