[libvirt] RFC: advertising graphics support (vnc, spice, sdl)
Currently consumers of libvirt's APIs must assume/attempt to define a VM that uses spice, vnc, or sdl without knowing if the actual hypervisor supports it. Obviously my discussion is very QEMU oriented but it would be good to leave expansion for the future. I was thinking that under the <guest> element for the capabilities we can add something like: <graphics> <spice/> <vnc/> <sdl/> </graphics> It would be at the same level as <arch> and <features>. But before I implemented this I wanted a sanity check if people think this is the best place or the best naming convention. Thanks. -- Doug Goldstein
On 19.10.2012 08:31, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to define a VM that uses spice, vnc, or sdl without knowing if the actual hypervisor supports it. Obviously my discussion is very QEMU oriented but it would be good to leave expansion for the future. I was thinking
Indeed. I look at libvirt as (sane) superset of hypervisor's features. Not their bare intersection.
that under the <guest> element for the capabilities we can add something like:
<graphics> <spice/> <vnc/> <sdl/> </graphics>
It would be at the same level as <arch> and <features>. But before I implemented this I wanted a sanity check if people think this is the best place or the best naming convention.
Thanks.
Makes sense to me. Michal
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to define a VM that uses spice, vnc, or sdl without knowing if the actual hypervisor supports it. Obviously my discussion is very QEMU oriented but it would be good to leave expansion for the future. I was thinking that under the <guest> element for the capabilities we can add something like:
<graphics> <spice/> <vnc/> <sdl/> </graphics>
This is something I've wanted to do for a long long time but my scope is much bigger: libvirt really needs to report near everything it knows about qemu emulator capabilities to the API user so we don't need to keep large whitelists in apps like virt-manager. That doesn't mean we couldn't start here though. The simplest place to put it is capabilties for sure, but if the scope is going to grow to cover more XML parameters it might be worth considering a separate API (but maybe we don't care if capabilities output is 100 pages long). The XML format could quickly get hairy if you assume that in the future maybe we want to report what graphics types support password or other arbitrary XML elements, but maybe that's getting into the realm of rng schema. - Cole
On Sun, Oct 21, 2012 at 3:26 PM, Cole Robinson <crobinso@redhat.com> wrote:
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to define a VM that uses spice, vnc, or sdl without knowing if the actual hypervisor supports it. Obviously my discussion is very QEMU oriented but it would be good to leave expansion for the future. I was thinking that under the <guest> element for the capabilities we can add something like:
<graphics> <spice/> <vnc/> <sdl/> </graphics>
This is something I've wanted to do for a long long time but my scope is much bigger: libvirt really needs to report near everything it knows about qemu emulator capabilities to the API user so we don't need to keep large whitelists in apps like virt-manager. That doesn't mean we couldn't start here though.
The simplest place to put it is capabilties for sure, but if the scope is going to grow to cover more XML parameters it might be worth considering a separate API (but maybe we don't care if capabilities output is 100 pages long).
The XML format could quickly get hairy if you assume that in the future maybe we want to report what graphics types support password or other arbitrary XML elements, but maybe that's getting into the realm of rng schema.
- Cole
I completely agree with you. My vision was bigger as well but I was trying to start small. The next item I was thinking of supporting would be IDE, SCSI, virtio, virtio-scsi. I really see this as being necessary per QEMU binary since you might have an ARM QEMU that supported different items than your x86_64 binary. I agree that XML could definitely get hairy once we start incorporating other systems like PPC, ARM, etc. We should probably look at breaking the capabilities up into some logical-ish sections. - host -- machine (power management, pae, acpi) -- cpu / memory /numa -- network -- security (apparmor, selinux) - guest (per arch) -- machine (power management, pae, acpi) -- cpu / memory / numa -- output (graphics) -- input (mouse, keyboard, usbredir?) enum virCapMachine { VIR_CAP_MACHINE_HOST, VIR_CAP_MACHINE_GUEST_X86, VIR_CAP_MACHINE_GUEST_AMD64, VIR_CAP_MACHINE_GUEST_ARM, VIR_CAP_MACHINE_GUEST_PPC, }; enum virCapType { VIR_CAP_TYPE_MACHINE, VIR_CAP_TYPE_CPUMEM, VIR_CAP_TYPE_OUTPUT, VIR_CAP_TYPE_INPUT, VIR_CAP_TYPE_NETWORK, VIR_CAP_TYPE_SECURITY, }; char *virCapabilitiesGet(enum virCapMachine, enum virCapType); or maybe just enum virCapHost { VIR_CAP_HOST_MACHINE, VIR_CAP_HOST_CPUMEM, VIR_CAP_HOST_NETWORK, VIR_CAP_HOST_SECURITY, }; enum virCapArch { VIR_CAP_ARCH_X86, VIR_CAP_ARCH_AMD64, VIR_CAP_ARCH_ARM, VIR_CAP_ARCH_PPC, }; enum virCapGuest { VIR_CAP_GUEST_MACHINE, VIR_CAP_GUEST_CPUMEM, VIR_CAP_GUEST_OUTPUT, VIR_CAP_GUEST_INPUT, }; char *virCapabilitiesGetHost(enum virCapHost); char *virCapabilitiesGetGuest(enum virCapArch, enum virCapGuest); Just an initial off the cuff thought. Definitely needs refinement and some better suggestions. -- Doug Goldstein
On Sun, Oct 21, 2012 at 04:26:39PM -0400, Cole Robinson wrote:
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to define a VM that uses spice, vnc, or sdl without knowing if the actual hypervisor supports it. Obviously my discussion is very QEMU oriented but it would be good to leave expansion for the future. I was thinking that under the <guest> element for the capabilities we can add something like:
<graphics> <spice/> <vnc/> <sdl/> </graphics>
This is something I've wanted to do for a long long time but my scope is much bigger: libvirt really needs to report near everything it knows about qemu emulator capabilities to the API user so we don't need to keep large whitelists in apps like virt-manager. That doesn't mean we couldn't start here though.
The simplest place to put it is capabilties for sure, but if the scope is going to grow to cover more XML parameters it might be worth considering a separate API (but maybe we don't care if capabilities output is 100 pages long).
The XML format could quickly get hairy if you assume that in the future maybe we want to report what graphics types support password or other arbitrary XML elements, but maybe that's getting into the realm of rng schema.
On the one hand we already have per-emulator capabilities in the current XML document, we machine types and the <features> block showing <cpuselection/> and <deviceboot/> flags. I think we should *not* put it in the existing capabilities XML document though, because I think this will get enourmous very quickly - particularly if you consider that we need to report this same data for every single QEMU emulator we detect - and there are alot of them now. So I think we ought to have a separate API that can be used to query just the specific emulator you want to use. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Doug Goldstein -
Michal Privoznik