It is a patch but beyond the unevitable spelling errors it contains I would appreciate some feedback on the content, which also defines the limits of the project. Some significant things to note in the diff below: - we do extend libvirt scope beyond purely managing domains, there is already a number of blocks which are here as helpr functions to manage the resources on the host. - we are expanding in the direction of libvirt being sufficient to do most of the management on the Host (but within the limits of the need for virtualization, e.g. managing users on the host is out of scope) - we don't require anymore APIs to be supported by multiple hypervisors to get in, it's already the case in practice, but we should still make sure the semantic of those APIs are clear. We added quite a bit for QEmu, but for example I saw on IRC that VBox could emulate a network unplug/replug on a domain interface, and that would be a good addition even if a priori no other hypervisor supports it. - Make clear that all libvirt APIs are available remotely, which is key to use libvirt for building management tools. - link the goal page from the project main page As for libvirt project directions, I think it just reflects the natural evolution in the last couple of years. We are less hypervisor agnostic and extending in the Host management. Clearly there is interest in making sure libvirt is complete in term of features for the hypervisors supported, especially the ones like KVM or LXC which don't really have integrated management library. Maybe I should have added a bit more about the security aspect, as integration of security context and making sure remote access are secured are very important additions to the library. Wording and content comments welcome, I guess we are all agreeing but the goals of the project as written are certainly up for discussion :-) Daniel diff --git a/docs/goals.html.in b/docs/goals.html.in index 8f0d075..6394709 100644 --- a/docs/goals.html.in +++ b/docs/goals.html.in @@ -16,20 +16,32 @@ <p class="image"> <img alt="Hypervisor and domains running on a node" src="node.gif"/> </p> - <p>Now we can define the goal of libvirt: to provide a common generic - and stable layer to securely manage domains on a node. The node may be - distant and libvirt should provide all APIs needed to provision, create, - modify, monitor, control, migrate and stop the domains, within the limits - of the support of the hypervisor for those operations. Multiple nodes may - be accessed with libvirt simultaneously but the APIs are limited to - single node operations.</p> + <p>Now we can define the goal of libvirt: <b> to provide a common and + stable layer sufficient to securely manage domains on a node, possibly + distant</b>.</p> + <p> As a result, libvirt should provide all APIs needed to do the + management like: provision, create, modify, monitor, control, migrate + and stop the domains - within the limits of the support of the hypervisor + for those operations. Some operations which may be hypervisor specific, + if needed for domain management should be provided too. Multiple nodes + may be accessed with libvirt simultaneously but the APIs are limited to + single node operations. Node ressource operations which are needed + for the management and provisioning of domains are also in the scope of + the libvirt API, like interface setup, firewall rules, storage management + and in general provisioning APIs. Libvirt will also provide the state + monitoring APIs needed to implement management policies, obviously + checking domain state but also expose local node resources consumption. + </p> <p>This implies the following sub-goals:</p> <ul> - <li>the API should not be targeted to a single virtualization environment - which also means that some very specific capabilities which are not generic - enough may not be provided as libvirt APIs</li> + <li>All API can be carried remotely though secure APIs</li> + <li>While most API will be generic in term of hypervisor or Host OS, + some API may be targeted to a single virtualization environment + as long as the semantic for the operations from a domain management + perspective is clear</li> <li>the API should allow to do efficiently and cleanly all the operations - needed to manage domains on a node</li> + needed to manage domains on a node including resource provisioning and + setup</li> <li>the API will not try to provide high level virtualization policies or multi-nodes management features like load balancing, but the API should be sufficient so they can be implemented on top of libvirt</li> diff --git a/docs/index.html.in b/docs/index.html.in index d40f652..64eb84d 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -8,7 +8,8 @@ <ul> <li> A toolkit to interact with the virtualization capabilities - of recent versions of Linux (and other OSes). + of recent versions of Linux (and other OSes), see our + <a href="goals.html">project goals</a> for details. </li> <li> Free software available under the -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/