[Libvir] virDomainConfigureDevice?
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need. The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on. None of this seems terribly hard, but before I go implement it, are there obvious pitfalls I'm not thinking? And given that virDomainAttachDevice is not implemented for qemud in libvirt (is it?), how do we handle the non-xen case? Thanks, --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock@redhat.com | virtualization library http://libvirt.org
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need.
The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on.
Definitely this will be useful for USB ... I think the question is: Should we have another entry point (virDomainConfigureDevice), or should we just modify virDomainAttachDevice so that if it sees XML for a device which is already attached it just modifies the device?
None of this seems terribly hard, but before I go implement it, are there obvious pitfalls I'm not thinking? And given that virDomainAttachDevice is not implemented for qemud in libvirt (is it?), how do we handle the non-xen case?
It seems like it isn't implemented for qemud. Changing the CD-ROM is possible through the qemu monitor, so it should be. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need.
The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on.
Definitely this will be useful for USB ...
I think the question is: Should we have another entry point (virDomainConfigureDevice), or should we just modify virDomainAttachDevice so that if it sees XML for a device which is already attached it just modifies the device?
It was raised previously that it's okay to recreate an existing domain to modify its configuration, then allowing virDomainAttachDevice to override an existing definition would be consistent with this. Another bonus point is one less entry point in the library and drivers. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need.
The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on. Definitely this will be useful for USB ...
I think the question is: Should we have another entry point (virDomainConfigureDevice), or should we just modify virDomainAttachDevice so that if it sees XML for a device which is already attached it just modifies the device?
It was raised previously that it's okay to recreate an existing domain to modify its configuration, then allowing virDomainAttachDevice to override an existing definition would be consistent with this. Another bonus point is one less entry point in the library and drivers.
Yes, that's right. I'm certainly in favor of reducing entry points, although if we allow virDomainAttachDevice to also modify existing devices, then it isn't quite named correctly... virDomainDefineDevice would probably be better. Too bad I guess. Next question is, how much protection do we want to build into the API? Do we want to rely on whatever hypervisor we're talking to to, for example, not allow us to change the back device for a disk on a running guest, or do we need to protect against that ourselves? --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock@redhat.com | virtualization library http://libvirt.org
On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
Daniel Veillard wrote:
It was raised previously that it's okay to recreate an existing domain to modify its configuration, then allowing virDomainAttachDevice to override an existing definition would be consistent with this. Another bonus point is one less entry point in the library and drivers.
Yes, that's right. I'm certainly in favor of reducing entry points, although if we allow virDomainAttachDevice to also modify existing devices, then it isn't quite named correctly... virDomainDefineDevice would probably be better. Too bad I guess.
yeah, still open question though, I would be fine adding a change entry point.
Next question is, how much protection do we want to build into the API? Do we want to rely on whatever hypervisor we're talking to to, for example, not allow us to change the back device for a disk on a running guest, or do we need to protect against that ourselves?
can we realistically do that ? And is that sensible ? Say we are changing a CD-Rom device, how would libvirt really check usage ? (the hypervisor might still keep a open fd on the file even if the domain does not use it at least until told to change to something else) I'm afraid those kind of checks are very unlikely to work correctly outside of the hypervisor itself. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
Daniel Veillard wrote:
It was raised previously that it's okay to recreate an existing domain to modify its configuration, then allowing virDomainAttachDevice to override an existing definition would be consistent with this. Another bonus point is one less entry point in the library and drivers.
Yes, that's right. I'm certainly in favor of reducing entry points, although if we allow virDomainAttachDevice to also modify existing devices, then it isn't quite named correctly... virDomainDefineDevice would probably be better. Too bad I guess.
yeah, still open question though, I would be fine adding a change entry point.
Next question is, how much protection do we want to build into the API? Do we want to rely on whatever hypervisor we're talking to to, for example, not allow us to change the back device for a disk on a running guest, or do we need to protect against that ourselves?
can we realistically do that ? And is that sensible ? Say we are changing a CD-Rom device, how would libvirt really check usage ? (the hypervisor might still keep a open fd on the file even if the domain does not use it at least until told to change to something else)
I'm afraid those kind of checks are very unlikely to work correctly outside of the hypervisor itself.
That's rather what I was thinking as I wrote the question. Fine, error checking will be limited to the usual "is the xml valid" stuff. Does anyone else have an opinion on whether to overload virDomainAttachDevice for modifying existing devices, or on the other hand add a new entry point like virDomainModifyDevice? --H -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock@redhat.com | virtualization library http://libvirt.org
On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need.
The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on. Definitely this will be useful for USB ...
I think the question is: Should we have another entry point (virDomainConfigureDevice), or should we just modify virDomainAttachDevice so that if it sees XML for a device which is already attached it just modifies the device?
It was raised previously that it's okay to recreate an existing domain to modify its configuration, then allowing virDomainAttachDevice to override an existing definition would be consistent with this. Another bonus point is one less entry point in the library and drivers.
Yes, that's right. I'm certainly in favor of reducing entry points, although if we allow virDomainAttachDevice to also modify existing devices, then it isn't quite named correctly... virDomainDefineDevice would probably be better. Too bad I guess.
Next question is, how much protection do we want to build into the API? Do we want to rely on whatever hypervisor we're talking to to, for example, not allow us to change the back device for a disk on a running guest, or do we need to protect against that ourselves?
Its impossible to protect against that. We have no knowledge about whether the guest has mounted the disk. The hypervisor *should* protect against that - eg the guest ought to be able to 'lock' the virtual CD tray to prevent media changes. Likewise the paravirt disk driver ought to be able to detect whether its frontend is mounted a fail. So leaving it upto the HV to protect is best. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need.
The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on.
Definitely this will be useful for USB ...
I think the question is: Should we have another entry point (virDomainConfigureDevice), or should we just modify virDomainAttachDevice so that if it sees XML for a device which is already attached it just modifies the device?
I don't mind too much either way. The only benefit a separate entry point would give is ability for an app to get an error back if they tried to modify a device which didn't exist. Whether they're separate or same entry point the underlying impls will be able to share a reasonable amount of code.
None of this seems terribly hard, but before I go implement it, are there obvious pitfalls I'm not thinking? And given that virDomainAttachDevice is not implemented for qemud in libvirt (is it?), how do we handle the non-xen case?
It seems like it isn't implemented for qemud. Changing the CD-ROM is possible through the qemu monitor, so it should be.
I intend to implement it when adding support for USB disk & device passthrough in QEMU/KVM. It will use the monitor for adding/removing USB devices on the fly. Likewise we can do CDROM media changes this way. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Hugh Brock -
Richard W.M. Jones