1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
<?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
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>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>
|
