Red Hat Bugzilla – Bug 1104992
Guest fail to start while disks use same no-exist source file even though with startupPolicy='optional'
Last modified: 2015-03-05 02:37:23 EST
Description of problem: Version-Release number of selected component (if applicable): Guest fail to start while disks use same no-exist source file even though with startupPolicy='optional' How reproducible: 100% Steps to Reproduce: 1. prepare a guest with two disk use the same no-exist source file # virsh dumpxml rhel6|grep disk -A 4 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2' startupPolicy='optional'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2' startupPolicy='optional'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> #ll /var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2 ls: cannot access /var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2: No such file or directory 2.Try to start guest # virsh start rhel6 error: Failed to start domain rhel6 error: invalid argument: no source device /var/lib/libvirt/images/kvm-rhel6.5-x86_64-qcow2 Actual results: Expected results: Guest should can boot up Additional info:
This is fixed upstream by v1.2.4-71-ga4693c7: commit a4693c76f5beb280869dac9d103ceb632c6c1403 Author: Jiri Denemark <jdenemar@redhat.com> Date: Thu May 15 13:11:12 2014 +0200 qemu: Avoid leak in qemuDomainCheckRemoveOptionalDisk Coverity complains about event being leaked in qemuDomainCheckRemoveOptionalDisk. The best fix for it is to remove the disk directly since we already know its index. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
verify version: libvirt-1.2.8-8.el7.x86_64 qemu-kvm-rhev-2.1.2-12.el7.x86_64 kernel-3.10.0-208.el7.x86_64 steps : 1.define and start a healthy domain: # virsh list Id Name State ---------------------------------------------------- 8 r7q2 running 2.the domain has two disks with same source file and startupPolicy=optional # virsh dumpxml r7q2 | grep disk -A 10 <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/r7q2.img' startupPolicy='optional'/> <backingStore/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/r7q2.img' startupPolicy='optional'/> <backingStore/> <target dev='vdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> 3.remove the disk file # mv r7q2.img r7q2.img.bak # ls r7q2.img ls: cannot access r7q2.img: No such file or directory 4.reboot the domain , domain start successfully # virsh destroy r7q2 ; virsh start r7q2 Domain r7q2 destroyed Domain r7q2 started 4.check the disk in domain XML , disk was dropped # virsh dumpxml r7q2 | grep disk -A 10 domain can start successfully , it can get expected results. Additional info: According to libvirt.org: For a "file" or "volume" disk type which represents a cdrom or floppy (the device attribute), it is possible to define policy what to do with the disk if the source file is not accessible. (NB, startupPolicy is not valid for "volume" disk unless the specified storage volume is of "file" type). so i have a test like this: 1.prepare a pool in which the volume is of 'file' type # virsh vol-list netfs-nfs-pool --details Name Path Type Capacity Allocation ------------------------------------------------------------------------------------------------------- disk.img /var/lib/libvirt/images/netfs-nfs/disk.img file 1.00 GiB 0.00 B qcow2.img /var/lib/libvirt/images/netfs-nfs/qcow2.img file 1.00 GiB 0.00 B 2.add the volume to domain # virsh dumpxml r7q2 | grep disk -A 10 <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='netfs-nfs-pool' volume='qcow2.img' startupPolicy='optional'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> <disk type='volume' device='disk'> <driver name='qemu' type='qcow2'/> <source pool='netfs-nfs-pool' volume='qcow2.img' startupPolicy='optional'/> <target dev='vdc' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </disk> 3.remove the volume # virsh vol-list netfs-nfs-pool --details Name Path Type Capacity Allocation ---------------------------------------------------------------------------------------------------- disk.img /var/lib/libvirt/images/netfs-nfs/disk.img file 1.00 GiB 0.00 B qcow2.img.bak /var/lib/libvirt/images/netfs-nfs/qcow2.img.bak file 1.00 GiB 196.00 KiB 4.reboot the domain , fail to start . can't find volume # virsh destroy r7q2 ; virsh start r7q2 Domain r7q2 destroyed error: Failed to start domain r7q2 error: Storage volume not found: no storage vol with matching path '/var/lib/libvirt/images/qcow2.img' Is it right use 'volume' disk type like above ? should it drop the missing volume and start successfully ? Thanks .
Yeah, the disk should be removed even if it is specified using pool/volume. Please, file a separate bug for it.
Thanks for the info . file a new bug 1168453 to track the issue . and according to comment 3 , move this bug to verified.
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://rhn.redhat.com/errata/RHSA-2015-0323.html