On 07/31/2010 01:52 AM, Daniel Veillard wrote:
>>> @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct
qemud_driver *driver, virDomainObjPtr vm)
>>> ret = qemuMonitorSetCapabilities(priv->mon);
>>> qemuDomainObjExitMonitorWithDriver(driver, vm);
>>>
>>> - ret = 0;
>>> error:
>>> if (ret < 0)
>>> qemuMonitorClose(priv->mon);
>>
>> Hum, if we do this we change the behaviour in case of errors in
>> qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid
>> failing in that case, and if this was the case then it's the first
>> affectation we need to remove. I would wait until this gets clarified
>> (qemuMonitorSetCapabilities failure may not be a blocking factor to
>> starting a guest ...)
>
> This bug was was introduced in commit e72cc3c, with dwalsh's patch on
> May 27. We were doing the correct thing before then, so only 0.8.2
> contains a problem where failure to connect to the monitor is undetected.
okidoc, ACK, sorry for the burden :-)
No problem - it was worth it to make me trawl through 'git gui blame',
since I learned more about how to effectively use it.
Now pushed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org