| Line 1... |
Line 1... |
| 1 |
# havirt
|
1 |
# havirt
|
| 2 |
|
2 |
|
| 3 |
### Script to macro manage cluster of nodes (hypervisors) and the domains
|
3 |
### Script to macro manage cluster of nodes (hypervisors) and the domains
|
| - |
|
4 |
(virtuals) on them.
|
| - |
|
5 |
|
| 4 |
(virtuals) on them. Used as an extension to virsh, which it calls quite often.
|
6 |
Used as an extension to virsh, which it calls quite often, but with a
|
| - |
|
7 |
cluster of nodes (hypervisors) with shared block devices (tested with
|
| - |
|
8 |
iSCSI).
|
| - |
|
9 |
|
| - |
|
10 |
Also, includes code to verify there are enough resources on a node
|
| - |
|
11 |
for the requested action, and protection against running the same domain
|
| - |
|
12 |
on multiple nodes simultaneously, which an result in block device
|
| - |
|
13 |
corruption.
|
| 5 |
|
14 |
|
| 6 |
All nodes must be able to make an ssh connection to all other nodes using
|
15 |
All nodes must be able to make an ssh connection to all other nodes using
|
| 7 |
public key (no passwords). Note that this includes being able to make an ssh
|
- |
|
| 8 |
connection to itself as, at this time, it simply makes an ssh connection to
|
- |
|
| 9 |
whatever node is defined.
|
16 |
public key (no passwords).
|
| 10 |
|
17 |
|
| 11 |
Very similar to virsh (on purpose); just adds some protection against
|
18 |
Very similar to virsh (on purpose); just adds some protection against
|
| 12 |
running domains on multiple nodes, allowing monitoring, etc... Samples are:
|
19 |
running domains on multiple nodes, allowing monitoring, etc... Samples are:
|
| 13 |
|
20 |
|
| 14 |
virsh start domainname # virsh way
|
21 |
virsh start domainname # virsh way
|
| Line 20... |
Line 27... |
| 20 |
resources, then start it on nodename (or the current node, if nodename not
|
27 |
resources, then start it on nodename (or the current node, if nodename not
|
| 21 |
specified) and modify it's state file to reflect the status change.
|
28 |
specified) and modify it's state file to reflect the status change.
|
| 22 |
|
29 |
|
| 23 |
The other difference is that the virsh command uses the configuration
|
30 |
The other difference is that the virsh command uses the configuration
|
| 24 |
domainname.xml stored in /etc/virtlib/qemu, while havirt does a 'virsh
|
31 |
domainname.xml stored in /etc/virtlib/qemu, while havirt does a 'virsh
|
| 25 |
create' using the domainname.xml stored in installdir/conf.
|
32 |
create' using the domainname.xml stored in installdir/conf. This allows
|
| - |
|
33 |
sharing of the same domain configuration on all nodes, at the expense of
|
| - |
|
34 |
some functionality.
|
| 26 |
|
35 |
|
| 27 |
By default, havirt will simply emit the command it will normally run. If the
|
36 |
By default, havirt will simply emit the command it will normally run. If the
|
| 28 |
--yes (-y) flag is passed, it will execute the command for you.
|
37 |
flag --dryrun is defaulted to false (0) in the config file, will actually
|
| - |
|
38 |
run the command(s) unless it is turned back on by passing as a cli
|
| - |
|
39 |
parameter (see config.sample.yaml).
|
| 29 |
|
40 |
|
| 30 |
havirt creates two subdirectories, installdir/conf/ and installdir/var/ if
|
41 |
havirt creates two subdirectories, installdir/conf/ and installdir/var/ if
|
| - |
|
42 |
they don't exist.
|
| - |
|
43 |
|
| 31 |
they don't exist. conf/ stores the xml configuration of all domains, while
|
44 |
conf/ stores the xml configuration of all domains
|
| 32 |
var/ stores the state file (yaml) and some temporary files.
|
45 |
var/ stores the state file (yaml) and some temporary files.
|
| 33 |
|
46 |
|
| 34 |
havirt also creates a configuration file (config.yaml) in the executables
|
47 |
havirt automatically creates a configuration file (config.yaml) in the executables
|
| 35 |
directory. This allows you to modify the default behaviour of the program
|
48 |
directory if it doesn't exist, allowing you to modify the default behavior
|
| 36 |
more easily. See config.sample.yaml if you want to manually create it,
|
- |
|
| 37 |
or for documentation on what can be modified.
|
49 |
of the system.
|