On Sun, Oct 21, 2012 at 3:26 PM, Cole Robinson <crobinso@xxxxxxxxxx> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list