On Wed, Jul 02, 2014 at 10:32:59AM -0400, John Ferlan wrote: > > diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in > > new file mode 100644 > > index 0000000..cfd61d9 > > --- /dev/null > > +++ b/docs/formatdomaincaps.html.in > > Since there's a "Capabilities" page describing the Driver (Host/Guest) > Capabilities and now this one for Domain - do you see a future need for > storage, network, etc. type capabilities? If so, other than the "volume > of data" then why not extend capabilities so that it could list > everything available for everything we know about? e.g.: > > <capabilities> > <host... /> > <guest... /> > <domain... /> > <storage... /> > <network... /> > <interface... /> > </capabilities> > > Architecturally, does it make sense to merge them or keep then separate? > There seems to be a relationship between them. Furthermore, if the goal > is to just provide information, then using one pile of xml output to > store everything may be useful to someone. For the more seasoned > individual using a specific/directed API that is planned will provide > the directed answer. I think the 'virsh capabilies' output certainly > shows it's possible to grab/use the various arch, machine, emulator, and > domain type values to generate lengthy output listing every possible option. First we want the <capabilities> XML to keep a reasonable size. If we listed everything in that one document, it would end up being many many MB in size. Second, the capabilities XML can only provide info on the default emulators known to libvirt. The separate API lets us get info on non-default emulator binaries too. To your original question though, I do see us adding more APIs in the future to query info about storage & networking. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list