Description of problem: Create a paravirt guest with the framebuffer configured, and then destroy it again. The /sys/class/xen-backend/devices/ directory will contain 2 nods for the VFB and VKBD devices. These nodes never appear to go away. Version-Release number of selected component (if applicable): kernel-2.6.18-84.el5 How reproducible: Always Steps to Reproduce: 1. Edit /etc/xen/GUEST and add 2.vfb = [ "type=vnc,vncunused=1"] 3. virsh start GUEST 4. Let it boot 5. virsh destroy GUEST 6. ls /sys/bus/xen-backend/devices/ Actual results: Two directories are still present: vfb-DOMID-0 vkbd-DOMID-0 Expected results: No directories are left behind Additional info:
The problem appears to be with the delegation of responsibility between the xenbus module, and the backend specific modules. The sysfs node is added when the xenbus_probe_node() method in the xenbus module calls device_register(). The corresponding call for device_unregister() though is in th backend specific modules. eg, the frontend_changed() method in the blkback module. There does not appear to be any generic fallback code in xenbus to call device_unregister() for device's whose backend lives in userspace such as VFB.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
In fact, when you do `xenstore-rm /local/domain/0/backend/{deviceClass}/{domid}` it automatically deletes those files in sysfs. I am working investigating it now...
I seems to be connected to BZ #439182. I've created and done workaround/patch and posted it to this BZ.
I'm going to close this as a dup of 439182, then. If it turns out to be different, we can re-open. Chris Lalancette *** This bug has been marked as a duplicate of bug 439182 ***