On Wed, May 09, 2012 at 05:01:25PM +0100, Daniel P. Berrange wrote: > Opps, no I was meaning /domain/cpu/feature here, which is the > same schem as /capabilities/host/cpu/feature. Ah thanks, that clears things up. > > I forgot there was also a /domain/features which corresponds > to /capabilities/guest/features Ok, this means gvir_config_domain_get_features should return a GList of GVirConfigCapabilitiesGuestFeature instead of raw char *, and gvir_config_domain_cpu_get_features (or whatever it's called, this does not exist yet) would return GVirConfigCapabilitiesCpuFeature? > > > I'm left with /capabilities/host/cpu/features (which correspond to > > Doh, I completely forgot about that. This is basically a bit of > legacy XML, which isn't even really used. It would only ever > be used to set 'pae', 'nonpae', 'vmx', or 'svm' flags. This is > the same kind of info as /capabilities/guest/features and also > /domain/features. > > The new /capabilities/host/cpu/feature is a superset of this info I guess libvirt-glib does not need to parse it if it's legacy? Thanks, Christophe
Attachment:
pgpwsVRnXpvtH.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list