Guido Günther wrote:
On Tue, Feb 10, 2009 at 09:32:49PM +0100, Stefan de Konink wrote:
Guido Günther wrote:
On Mon, Feb 09, 2009 at 11:30:30AM -0500, Cole Robinson wrote: [..snip..]
No fault of this patch, but this makes me ask the question: what exactly are attachDevice and detachDevice supposed to do?
In the qemu driver, it is entirely hotplug/hotunplug, and deliberately fails on an inactive domain. This patch seems to add offline support We don't even persist the devices being hot{added,removed} into the domain xml so acting on inactive domains has no meaning or am I missing something? When the domain is enabled, and you store it... you basically get that behavior. Exactly my point: when the domain is *enabled*.
I'm a little lost. My point was basically that with this patch to xend, attach/detach has different meanings between the qemu + xend driver. qemu : vm active : attempt to hotplug the device and persist xml changes on success, raise error if device is not not hotpluggable vm inactive : deliberately fail: 'vm must be active' xen : vm active : attempt to hotplug device, unknown if changes are persisted, unknown result if device is not hotpluggable (unknown to me, anyways) vm inactive : _dont_ fail, add device to VM config The libvirt docs for attach/detach device are: attachDevice: Create a virtual device attachment to backend. detachDevice: Destroy a virtual device attachment to backend. Not very helpful. All I want is some understanding of what attach/detach is supposed to mean :) Adding the device to the xml for an inactive domain is fine by me (though it would essentially be a convenience function), but I would like to ensure that if the domain is active and the device is not hotpluggable, we throw a failure. Without that, there isn't any way to determine that attachDevice on the active domain did anything immediately useful. Thanks, Cole