[libvirt] RFC: advertising graphics support (vnc, spice, sdl)

Doug Goldstein cardoe at gentoo.org
Sun Oct 21 21:29:28 UTC 2012


On Sun, Oct 21, 2012 at 3:26 PM, Cole Robinson <crobinso at 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




More information about the libvir-list mailing list