Bug 1554028
| Summary: | "No space left on device" error when copying a disk based on template to a block domain in DC <= 4.0 when the disk was extended | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Elad <ebenahar> | ||||||
| Component: | BLL.Storage | Assignee: | Benny Zlotnik <bzlotnik> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Kevin Alon Goldblatt <kgoldbla> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 4.2.0 | CC: | amureini, apinnick, bugs, bzlotnik, ebenahar, tnisan | ||||||
| Target Milestone: | ovirt-4.2.2 | Flags: | rule-engine:
ovirt-4.2+
rule-engine: exception+ |
||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||
| Doc Text: |
Previously, with storage domains of data centers with compatibility version 4.0 or earlier, if a virtual disk based on a template disk was extended and moved during live storage migration, the move operation failed because the child image was larger than the parent image (template disk). In the current release, the move operation of such disks displays an error message instead of failing. The resolution for this scenario is to upgrade the data center to compatibility version 4.1 or later.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2018-04-05 09:38:28 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Elad
2018-03-10 20:30:18 UTC
This is definitely a bug, but offhand, it does not look related to qemu's new locking mechanism. Actually, it looks similar to bug 1523614, and probably has to do with some subtle between qcow2's compat levels. Elad, let's try to isolate the problem. Can you run the same scenario on RHEL 7.4.z (with qemu 2.9.something) and double check whether it reproduces? I'm tentatively targetting this to 4.2.2 under the assumption it really is a regression. If the aforementioned requested analysis proves otherwise, we can rethink the targeting. This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Created attachment 1406852 [details]
rhel-7.4
The bug doesn't reproduce on RHEL7.4.
2018-03-11 13:09:57,665+0200 INFO (jsonrpc/1) [vdsm.api] FINISH syncImageData return=None from=::ffff:10.35.161.181,36978, flow_id=78d95342-cee0-4114-af41-d2b429270026, task_id=1b966efd-bb1d-4b2f-a784-817a19ad3
160 (api:52)
[root@storage-ge1-vdsm1 ~]# rpm -qa |egrep 'vdsm|libvirt|qemu'
qemu-kvm-tools-rhev-2.10.0-21.el7.x86_64
qemu-guest-agent-2.8.0-2.el7.x86_64
qemu-kvm-rhev-2.10.0-21.el7.x86_64
libvirt-daemon-driver-interface-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.9.x86_64
vdsm-yajsonrpc-4.19.48-1.el7ev.noarch
vdsm-hook-vmfex-dev-4.19.48-1.el7ev.noarch
libvirt-libs-3.2.0-14.el7_4.9.x86_64
vdsm-xmlrpc-4.19.48-1.el7ev.noarch
libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-kvm-3.2.0-14.el7_4.9.x86_64
vdsm-cli-4.19.48-1.el7ev.noarch
libvirt-daemon-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.9.x86_64
vdsm-hook-localdisk-4.19.48-1.el7ev.noarch
qemu-img-rhev-2.10.0-21.el7.x86_64
vdsm-api-4.19.48-1.el7ev.noarch
qemu-kvm-common-rhev-2.10.0-21.el7.x86_64
libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-lxc-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.9.x86_64
vdsm-hook-ethtool-options-4.19.48-1.el7ev.noarch
libvirt-3.2.0-14.el7_4.9.x86_64
vdsm-python-4.19.48-1.el7ev.noarch
libvirt-daemon-driver-network-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-config-network-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-3.2.0-14.el7_4.9.x86_64
libvirt-python-3.2.0-3.el7_4.1.x86_64
libvirt-client-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-secret-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.9.x86_64
vdsm-jsonrpc-4.19.48-1.el7ev.noarch
vdsm-4.19.48-1.el7ev.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libvirt-daemon-config-nwfilter-3.2.0-14.el7_4.9.x86_64
libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.9.x86_64
libvirt-lock-sanlock-3.2.0-14.el7_4.9.x86_64
[root@storage-ge1-vdsm1 ~]# cat /etc/os-release
PRETTY_NAME="Red Hat Enterprise Linux Server 7.4 (Maipo)"
[root@storage-ge1-vdsm1 ~]# uname -a
Linux storage-ge1-vdsm1.scl.lab.tlv.redhat.com 3.10.0-693.21.1.el7.x86_64 #1 SMP Fri Feb 23 18:54:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
It appears to be a similar bug to https://bugzilla.redhat.com/show_bug.cgi?id=1523614 The case there is that we have a snapshot and then we extend the disk, which results in having a child snapshot bigger then its parent. The case here is that we extend the VM disk, which results in a child image bigger than its parent (the template's image) Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. Benny,can you please add some doctext explaining the situation and what a user can be done to overcome it? Verified with the following code: ---------------------------------------- ovirt-engine-4.2.2.6-0.1.el7.noarch vdsm-4.20.23-1.el7ev.x86_64 Verified with the following scenario: ------------------------------------------- Steps to Reproduce: - Created a 4.0 DC and cluster with RHEL7.5 host - Created a NFS domain (created as v3) - Created a template - Created 2 VMs from the template as thin copy (VM image is based on the template) - created as qcow2 - Created a second storage domain (iSCSI) - Copied template disk to the second storage domain - Started both VMs - Tried to move one of the VMs disk to the second domain >>>>> disk move operation was successfull Moving to VERIFIED Verified with the following code: ---------------------------------------- ovirt-engine-4.2.2.6-0.1.el7.noarch vdsm-4.20.23-1.el7ev.x86_64 CORRECTION TO SCENARIO Verified with the following scenario: ------------------------------------------- Steps to Reproduce: - Created a 4.0 DC and cluster with RHEL7.5 host - Created a NFS domain (created as v3) - Created a template - Created 2 VMs from the template as thin copy (VM image is based on the template) - created as qcow2 - Created a second storage domain (iSCSI) - Copied template disk to the second storage domain - Started both VMs - Extend the disk of one of the VMs (Added this step) - Tried to move the extended disk to the second domain >>>>> This operation fails as expected Moving to VERIFIED This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |