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