On 11/20/2009 01:39 PM, Jim Fehlig wrote:
> Daniel Veillard wrote:
>> On Mon, Nov 16, 2009 at 04:06:41PM -0700, Jim Fehlig wrote:
>>
>>> virDomain{Attach,Detach}Device is only permitted on active
>>> domains. Explicitly state this restriction in the API
>>> documentation.
>>>
>>
>> Well, actually I'm not sure it's true. For exemple the
>> XML xen driver has an implementation for inactive Xen domains,
>> and if I look at the VirtualBox driver it seems to take care
>> of domains which are not currently running (or paused).
>>
>
> So what do folks prefer? Allow the individual drivers to restrict
> attach/detach device or enforce restriction in the front-end? IMO, it
> should be delegated to the individual drivers, with a comment in the API
> description that some hypervisors may not support this operation on
> inactive domains. Why restrict a hypervisor's management functionality
> in the libvirt front-end?
>
Because it introduces hypervisor dependent API differences that aren't
programmatically discoverable. This makes life difficult for apps that
want to support multiple hypervisors (like virt-manager, where we have
already bumped up against this inconsistency between xen and qemu
drivers). In this case, if xen allows offline device addition but qemu
does not, virt-manager will have to use the safe subset and never
attempt attach device for an offline VM, or hardcode HV differences into
the app.
For that reason, I think we should either always allow offline
AttachDevice or never allow it. And of the two, I highly favor the
latter, since the alternative would force every driver to reimplement
something that can easily be accomplished with DefineXML (unless the HV
supports it natively, which in Xen's case sounds like it isn't handled
consistently for all device types).
Maybe a way forward here is to clarify the virsh commands: we can alter
attach/detach-device to manually edit the VM xml for inactive VMs (but
also attempt hotplug if the VM is running), and introduce new commands
hotplug-device and hotunplug-device which map straight through to the
API. This way virsh won't regress, and indeed will improve: only
straight API users will see a change in behavior.
Thanks,
Cole
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list