Bug 601067
| Summary: | Using a self recursive snapshot backing store *takes out* libvirtd | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Justin Clift <justin> |
| Component: | libvirt | Assignee: | Daniel Berrangé <berrange> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | ajia, berrange, dallan, hbrock, mjenner, weizhan, xen-maint, xhu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0_8_1-14_el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-11 14:48:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 609432 | ||
Opps, that's a very nasty bug, even if this is a crazy config :-) Clearly we need to figure out how to fix this. Should also check that qemu handles this scenario sensibly. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. libvirt-0_8_1-14_el6 has been built in RHEL-6-candidate with the fix. Dave Verify steps:
1.create qcow2 snapshot volume
#qemu-img create -f qcow2 -o backing_file=/home/images/sdbimagesnap2.qcow2,backing_fmt=host_device /home/images/sdbimagesnap2.qcow2 20G
Formatting '/home/images/sdbimagesnap2.qcow2', fmt=qcow2 size=21474836480
backing_file='/home/images/sdbimagesnap2.qcow2' backing_fmt='host_device'
encryption=off cluster_size=0
2. define qcow2-img.xml
#cat qcow2-img.xml
<domain type='kvm'>
<name>qcow2-img</name>
<uuid>c77b3a27-1bfb-65bd-6212-c72127d63af3</uuid>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='rhel6.0.0'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='qcow2'/>
<source dev='/var/lib/libvirt/images/sdbimagesnap2.qcow2'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='network'>
<mac address='52:54:00:dd:50:97'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target port='0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
</devices>
</domain>
#virsh define qcow2-img.xml
3. start vm
#virsh start qcow2-img
error: Failed to start domain qcow2-img
error: internal error backing store for /var/lib/libvirt/images/sdbimagesnap2.qcow2 is self-referential
Boot guest VM failed. What about the error information on the second line? Is that right? Does it mean the bug is fixed?
version:
libvirt-0.8.1-18.el6.x86_64
kernel 2.6.32-52.el6.x86_64
Yes, that error message is correct. If libvirt is still responsive after that error message, the bug is fixed. Verified this bug with RHEL6 RC build and it passed: libvirt-0.8.1-27.el6.x86_64 qemu-kvm-0.12.1.2-2.113.el6.x86_64 kernel-2.6.32-71.el6.x86_64 Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |
Description of problem: On RHEL 6 beta, when using a qcow2 snapshot volume that references itself as a backing store, libvirtd goes into a continuous loop when the VM is started. It's effectively hard-locked, and need to be kill -9'd. For example: # qemu-img create -f qcow2 -o backing_file=/home/images/sdbimagesnap2.qcow2,backing_fmt=host_device /home/images/sdbimagesnap2.qcow2 20G Formatting '/home/images/sdbimagesnap2.qcow2', fmt=qcow2 size=21474836480 backing_file='/home/images/sdbimagesnap2.qcow2' backing_fmt='host_device' encryption=off cluster_size=0 # With a VM that uses it like: <disk type='block' device='disk'> <driver name='qemu' type='qcow2'/> <source dev='/home/images/sdbimagesnap2.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> When the VM is started, libvirtd effectively hard locks. Logs from the libvirtd daemon show: 17:08:49.926: info : qemuSecurityDACSetOwnership:40 : Setting DAC context on '/home/images/sdbimagesnap2.qcow2' to '0:0' 17:08:49.926: info : qemuSecurityDACSetOwnership:40 : Setting DAC context on '/home/images/sdbimagesnap2.qcow2' to '0:0' 17:08:49.926: info : qemuSecurityDACSetOwnership:40 : Setting DAC context on '/home/images/sdbimagesnap2.qcow2' to '0:0' At a logging rate of 10,000 - 40,000+ new log lines per second until it's kill -9'd. It does this even on a server which has had SELinux disabled: # getenforce 0 Disabled # Version-Release number of selected component (if applicable): libvirt-0.7.6-2.el6.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Manually create a self-referencing snapshot with qemu-img. 2. Define a virtual machine using this snapshot volume. 3. Start the virtual machine. libvirtd will go into an endless loop now. Actual results: libvirtd goes into an endless loop. The guest virtual machine never gets to start. Expected results: Failure to boot in the guest VM. Additional info: