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