Re: [libvirt] RFC: advertising graphics support (vnc, spice, sdl)
On Sun, Oct 21, 2012 at 3:26 PM, Cole Robinson <crobinso(a)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