Red Hat Bugzilla – Bug 800253
[libvirt] missing 'source file' attribute when passing 'optional' param in xml
Last modified: 2014-01-12 19:51:16 EST
Description of problem:
bug was originally opened for RHEL - https://bugzilla.redhat.com/show_bug.cgi?id=795093
we need this back-port for Fedora.
missing 'source dev' attribute when passing 'optional' param in XML with
regardless wither source-dev exists or not.
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<address type='drive' controller='0' bus='1' unit='0'/>
vmId=`2aed27de-bc3f-40cb-85b3-1839f8e38279`::Stats function failed:
<AdvancedStatsFunction _sampleDiskLatency at 0x207a7a0>
Traceback (most recent call last):
File "/usr/share/vdsm/utils.py", line 395, in collect
File "/usr/share/vdsm/utils.py", line 272, in __call__
retValue = self._function(*args, **kwargs)
File "/usr/share/vdsm/libvirtvm.py", line 158, in _sampleDiskLatency
diskLatency[vmDrive.name] = stats[vmDrive.alias]
AttributeError: 'Drive' object has no attribute 'alias'
domain was started with
<disk device="cdrom" snapshot="no" type="file">
<target bus="ide" dev="hdc"/>
the source file is accessible on the nfs mount. However, libvirt claims
2012-02-19 11:54:41.779+0000: 22269: debug : qemuDomainCheckDiskPresence:1634 :
Dropping disk 'hdc' on domain 'xtream-vm-001' (UUID
'f9ea04b0-1a1e-4793-870f-b3b1f8b6c6e4') due to inaccessible source
and drops the "file" attribute from the <source> element.
If startupPolicy="optional" is dropped, the domain starts up fine.
note also that libvirt's behaviour is inconsistent with the case of starting
with an empty cdrom. There, the <source> element is completely dropped from
We need to backport the following upstream commit to F16:
Author: Michal Privoznik <email@example.com>
Date: Wed Feb 22 09:55:27 2012 +0100
util: Fix virFileAccessibleAs return path from parent
Despite documentation, if we do fork() parent always returns -1
even if file is accessible. Which is wrong obviously.
On further investigation - that patch doesn't apply to libvirt in Fedora 16 (0.9.6) because the function virFileAccessibleAs doesn't yet exist, nor does the caller of that function (qemuDomainCheckDiskPresence).
This is going to need a farther-reaching (or at least different) backport than the one patch indicated above. To figure out what needs to be backported, can you provide the error log produced when running libvirt-0.9.6 (the version that's in Fedora 16)?
(In reply to comment #2)
> On further investigation - that patch doesn't apply to libvirt in Fedora 16
> (0.9.6) because the function virFileAccessibleAs doesn't yet exist, nor does
> the caller of that function (qemuDomainCheckDiskPresence).
> This is going to need a farther-reaching (or at least different) backport than
> the one patch indicated above. To figure out what needs to be backported, can
> you provide the error log produced when running libvirt-0.9.6 (the version
> that's in Fedora 16)?
2012-03-21 08:25:32.554+0000: 3279: debug : qemuDomainCheckDiskPresence:1737 : Dropping disk 'hdc' on domain 'MyVm3-0-Windows' (UUID '301d5fdb-cb3c-4c17-81ce-98f0e654b023') due to inaccessible source '/rhev/data-center/fcb97cf1-42f3-4a2
startupPolicy is even not supported on f16, if we want to support it, we have to backport the whole patches for startupPolicy and a bunch of follow up small problem fixing patches. Much conflicts, and it might casue regression or something
like risk, so I'd think we should fix the problem on f17 instead, f17 already supported the startupPolicy, but just doesn't work well for the bug.
*** Bug 805411 has been marked as a duplicate of this bug. ***
Yeah, this isn't backport material IMO. If vdsm is wants to support multiple versions of libvirt it will need to tease these issues out.