Jan Beulich wrote:
>>>> "James (song wei)" <jsong@xxxxxxxxxx> 22.04.10 10:08 >>>
>>>>
>> --- a/tools/python/xen/xend/XendDomainInfo.py Mon Apr 19 17:57:28 2010
>> +0100
>> +++ b/tools/python/xen/xend/XendDomainInfo.py Thu Apr 22 15:54:01 2010
>> +0800
>> @@ -2406,8 +2406,13 @@
>>
>> def _releaseDevices(self, suspend = False):
>> """Release all domain's devices. Nothrow guarantee."""
>> + t = xstransact("%s/device" % self.vmpath)
>> if self.image:
>> try:
>> + for dev in t.list('tap'):
>> + log.debug("Early removing %s", dev);
>> + self.getDeviceController('tap').destroyDevice(dev, True)
>> + time.sleep(0.1)
>> log.debug("Destroying device model")
>> self.image.destroyDeviceModel()
>> except Exception, e:
>> @@ -2416,9 +2421,10 @@
>> log.debug("No device model")
>>
>> log.debug("Releasing devices")
>> - t = xstransact("%s/device" % self.vmpath)
>> try:
>> for devclass in XendDevices.valid_devices():
>> + if devclass is 'tap':
>> + continue
>> for dev in t.list(devclass):
>> try:
>> log.debug("Removing %s", dev);
>>
>
> This seems more like a hack than a solution: Surely qemu-dm gets
> sent some sort of signal to shut down and clean up. The question
> thus really is why that cleanup doesn't include cleaning up blktap
> related resources. That is, I would expect the fix to be in qemu-dm,
> or at most in the xend code that reaps qemu-dm.
>
Agreed. qemu-dm should clean up these resources on shutdown. AFAICT,
it currently relies on receiving CTRMSG_CLOSE from blktapctrl (see
ioemu-dir/hw/xen_blktap.c), which it may never receive before exiting.
Regards,
Jim
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home