On 03/24/2011 04:40 AM, Daniel Veillard wrote: > 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> I think 'possibly remote' reads better than 'possibly distant'. > + <p> As a result, libvirt should provide all APIs needed to do the > + management like: provision, create, modify, monitor, control, migrate s/management like/management, such as/ > + 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. Yes, it makes sense to document that we don't mind providing well-documented hypervisor-specific operations. But the wording might sound better as: Not all hypervisors provide the same operations; but if an operation is useful for domain management of even one specific hypervisor it is worth providing in libvirt. > Multiple nodes > + may be accessed with libvirt simultaneously but the APIs are limited to s/ but/, but/ > + single node operations. Node ressource operations which are needed s/ressource/resource/ > + 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. s/like/such as/ s/and in general/and general/ > Libvirt will also provide the state > + monitoring APIs needed to implement management policies, obviously > + checking domain state but also expose local node resources consumption. s/expose local node resources/exposing local node resource/ > <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> I agree with this change. > <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> s/node including/node, including/ -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list