2009-04-02 12:01:11 +00:00
|
|
|
<?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: 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
|
2010-05-07 17:52:35 +00:00
|
|
|
of the support of the hypervisor for those operations. Multiple nodes may
|
2009-04-02 12:01:11 +00:00
|
|
|
be accessed with libvirt simultaneously but the APIs are limited to
|
|
|
|
|
single node operations.</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>the API should allow to do efficiently and cleanly all the operations
|
|
|
|
|
needed to manage domains on a node</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>
|
