mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-25 01:34:11 +03:00
50d8ad828d
Some things to note in this patch:
- 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.
* docs/goals.html.in: update the goals page
* docs/index.html.in: link it from the top page
67 lines
3.5 KiB
XML
67 lines
3.5 KiB
XML
<?xml version="1.0"?>
|
|
<html>
|
|
<body>
|
|
<h1>Terminology and goals</h1>
|
|
<p>To avoid ambiguity about the terms used, here are the definitions
|
|
for some of the specific concepts used in libvirt documentation:</p>
|
|
<ul>
|
|
<li>a <strong>node</strong> is a single physical machine</li>
|
|
<li>an <strong>hypervisor</strong> is a layer of software allowing to
|
|
virtualize a node in a set of virtual machines with possibly different
|
|
configurations than the node itself</li>
|
|
<li>a <strong>domain</strong> is an instance of an operating system
|
|
(or subsystem in the case of container virtualization) running on a
|
|
virtualized machine provided by the hypervisor</li>
|
|
</ul>
|
|
<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: <b> to provide a common and
|
|
stable layer sufficient to securely manage domains on a node, possibly
|
|
remote</b>.</p>
|
|
<p> As a result, libvirt should provide all APIs needed to do the
|
|
management, such as: provision, create, modify, monitor, control, migrate
|
|
and stop the domains - within the limits of the support of the hypervisor
|
|
for those operations.
|
|
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
|
|
single node operations. Node resource operations which are needed
|
|
for the management and provisioning of domains are also in the scope of
|
|
the libvirt API, such as interface setup, firewall rules, storage management
|
|
and general provisioning APIs. Libvirt will also provide the state
|
|
monitoring APIs needed to implement management policies, obviously
|
|
checking domain state but also exposing local node resource consumption.
|
|
</p>
|
|
<p>This implies the following sub-goals:</p>
|
|
<ul>
|
|
<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, 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>
|
|
<li>stability of the API is a big concern, libvirt should isolate
|
|
applications from the frequent changes expected at the lower level of the
|
|
virtualization framework</li>
|
|
<li>the node being managed may be on a different physical machine than
|
|
the management program using libvirt, to this effect libvirt supports
|
|
remote access, but should only do so by using secure protocols.</li>
|
|
<li>libvirt will provide APIs to enumerate, monitor and use the resources
|
|
available on the managed node, including CPUs, memory, storage, networking,
|
|
and NUMA partitions.</li>
|
|
</ul>
|
|
<p>So libvirt is intended to be a building block for higher level
|
|
management tools and for applications focusing on virtualization of a
|
|
single node (the only exception being domain migration between node
|
|
capabilities which involves more than one node).</p>
|
|
</body>
|
|
</html>
|