Bug 1442344
Summary: | domblkinfo doesn't work for iscsi/rbd backend virtual disk | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | yisun |
Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
Status: | CLOSED ERRATA | QA Contact: | Han Han <hhan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.4 | CC: | hhan, jiyan, lmen, pkrempa, pzhang, rbalakri, xuzhang, yisun |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-3.2.0-4.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-02 00:05:54 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: | |
Embargoed: |
Description
yisun
2017-04-14 08:14:41 UTC
Hi yisun, what about nbd backend? (In reply to Han Han from comment #3) > Hi yisun, what about nbd backend? Doesn't work root@localhost ~ ## virsh domblklist vm1 Target Source ------------------------------------------------ vda /var/lib/libvirt/images/rhel7.3.qcow2 vdb - vdc libvirt-pool/rbd1.img vdd /var/lib/libvirt/images/1.qcow2 root@localhost ~ ## virsh domblkinfo vm1 vdb error: internal error: missing storage backend for network files using nbd protocol This was caused by commit [1]. The code previously updated the physical size only for block devices and thus would rely on data from qemu in other cases. With this change virStorageSourceUpdatePhysicalSize tries to open the storage source also for networked storage protocols where we did not implement the handlers yet. Since the failure of qemuDomainStorageUpdatePhysical is fatal in case of qemuDomainBlockGetInfo, this fails for all storage protocols which are not implemented. Additionally commit [2] made it more likely to call the function. We need to fix this by skipping the call if qemuDomainStorageUpdatePhysical and the underlying functions are not implemented and return incomplete data as we would until now. [1] commit c5f6151390ff0a8e65014172bb8c0a8d312c3353 Author: John Ferlan <jferlan> Date: Thu Dec 1 16:19:26 2016 -0500 util: Introduce virStorageSourceUpdatePhysicalSize Commit id '8dc27259' introduced virStorageSourceUpdateBlockPhysicalSize in order to retrieve the physical size for a block backed source device for an active domain since commit id '15fa84ac' changed to use the qemuMonitorGetAllBlockStatsInfo and qemuMonitorBlockStatsUpdateCapacity API's to (essentially) retrieve the "actual-size" from a 'query-block' operation for the source device. However, the code only was made functional for a BLOCK backing type and it neglected to use qemuOpenFile, instead using just open. After the open the block lseek would find the end of the block and set the physical value, close the fd and return. Since the code would return 0 immediately if the source device wasn't a BLOCK backed device, the physical would be displayed incorrectly, such as follows in domblkinfo for a file backed source device: Capacity: 1073741824 Allocation: 0 Physical: 0 This patch will modify the algorithm to get the physical size for other backing types and it will make use of the qemuDomainStorageOpenStat helper in order to open/stat the source file depending on its type. The qemuDomainGetStatsOneBlock will no longer inhibit printing errors, but it will still ignore them leaving the physical value set to 0. [2] commit b9b1aa6392e058b9c3814ea391943bc3be18ccba Author: John Ferlan <jferlan> Date: Mon Dec 12 17:12:09 2016 -0500 qemu: Adjust qemuDomainGetBlockInfo data for sparse backed files According to commit id '0282ca45a' the 'physical' value should essentially be the last offset of the image or the host physical size in bytes of the image container. However, commit id '15fa84ac' refactored the GetBlockInfo to use the same returned data as the GetStatsBlock API for an active domain. For the 'entry->physical' that would end up being the "actual-size" as set through the qemuMonitorJSONBlockStatsUpdateCapacityOne (commit '7b11f5e5'). Digging deeper into QEMU code one finds that actual_size is filled in using the same algorithm as GetBlockInfo has used for setting the 'allocation' field when the domain is inactive. The difference in values is seen primarily in sparse raw files and other container type files (such as qcow2), which will return a smaller value via the stat API for 'st_blocks'. Additionally for container files, the 'capacity' field (populated via the QEMU "virtual-size" value) may be slightly different (smaller) in order to accomodate the overhead for the container. For sparse files, the state 'st_size' field is returned. This patch thus alters the allocation and physical values for sparse backed storage files to be more appropriate to the API contract. The result for GetBlockInfo is the following: capacity: logical size in bytes of the image (how much storage the guest will see) allocation: host storage in bytes occupied by the image (such as highest allocated extent if there are no holes, similar to 'du') physical: host physical size in bytes of the image container (last offset, similar to 'ls') NB: The GetStatsBlock API allows a different contract for the values: "block.<num>.allocation" - offset of the highest written sector as unsigned long long. "block.<num>.capacity" - logical size in bytes of the block device backing image as unsigned long long. "block.<num>.physical" - physical size in bytes of the container of the backing image as unsigned long long. Fixed upstream: commit 9f16bb7386939c400a7522d2489245f1e6831bae Author: Peter Krempa <pkrempa> Date: Thu Apr 20 11:16:42 2017 +0200 qemu: Don't fail if physical size can't be updated in qemuDomainGetBlockInfo Since commit c5f6151390 qemuDomainBlockInfo tries to update the "physical" storage size for all network storage and not only block devices. Since the storage driver APIs to do this are not implemented for certain storage types (RBD, iSCSI, ...) the code would fail to retrieve any data since the failure of qemuDomainStorageUpdatePhysical is fatal. Since it's desired to return data even if the total size can't be updated we need to ignore errors from that function and return plausible data. Verified on: qemu-kvm-rhev-2.9.0-3.el7.x86_64 libvirt-3.2.0-4.virtcov.el7.x86_64 As we know, the network protocols that qemu-kvm-rhev and libvirt both suppport are: iscsi, nbd, rbd, gluster, https. steps: 1. Start a VM with iscsi, nbd, rbd, gluster, https storage: <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2016-12.com.virttest:emulated-iscsi-noauth.target0/0'> <host name='10.66.5.92' port='3260'/> </source> <backingStore/> <target dev='sdb' bus='scsi'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='nbd' name='nbd_raw'> <host name='10.66.5.92' port='10803'/> </source> <backingStore/> <target dev='sdc' bus='scsi'/> <alias name='scsi0-0-0-2'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='rbd' name='rbd/rbd.img'> <host name='10.73.75.52'/> </source> <backingStore/> <target dev='sdd' bus='scsi'/> <alias name='scsi0-0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> <disk type='network' device='disk'> <driver name='qemu' type='qcow2'/> <source protocol='gluster' name='gluster-vol1/16572.qcow2'> <host name='10.66.5.92'/> </source> <backingStore/> <target dev='sde' bus='scsi'/> <alias name='scsi0-0-0-4'/> <address type='drive' controller='0' bus='0' target='0' unit='4'/> </disk> <disk type='network' device='cdrom'> <driver name='qemu' type='raw'/> <source protocol='https' name='/pub/fedora/linux/releases/25/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-25-1.3.iso'> <host name='download.fedoraproject.org' port='443'/> </source> <backingStore/> <target dev='sdf' bus='scsi'/> <readonly/> <alias name='scsi0-0-0-5'/> <address type='drive' controller='0' bus='0' target='0' unit='5'/> </disk> 2. Check their domblkinfo # for dev in sd{b..f};do virsh domblkinfo Q $dev;done Capacity: 32212254720 Allocation: 32212254720 Physical: 32212254720 Capacity: 10737418240 Allocation: 10737418240 Physical: 10737418240 Capacity: 5368709120 Allocation: 5368709120 Physical: 5368709120 Capacity: 10737418240 Allocation: 1356791808 Physical: 1356791808 Capacity: 486539264 Allocation: 486539264 Physical: 486539264 All results are expected. Bug fixed. 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/RHEA-2017:1846 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/RHEA-2017:1846 |