root / README @ 79224631
History | View | Annotate | Download (6.1 kB)
1 |
ganeti-instance-debootstrap |
---|---|
2 |
=========================== |
3 |
|
4 |
This is a guest OS definition for Ganeti (http://code.google.com/p/ganeti). |
5 |
It will install a minimal version of Debian or Ubuntu via debootstrap (thus it |
6 |
requires network access). This only works if you have a Debian-based node or |
7 |
you have debootstrap installed by hand on another distribution. |
8 |
|
9 |
Installation |
10 |
------------ |
11 |
|
12 |
In order to install this package from source, you need to determine what |
13 |
options ganeti itself has been configured with. If ganeti was built |
14 |
directly from source, then the only place it looks for OS definitions is |
15 |
``/srv/ganeti/os``, and you need to install the OS under it:: |
16 |
|
17 |
./configure --prefix=/usr --localstatedir=/var \ |
18 |
--sysconfdir=/etc \ |
19 |
--with-os-dir=/srv/ganeti/os |
20 |
make && make install |
21 |
|
22 |
If ganeti was installed from a package, its default OS path should |
23 |
already include /usr/share/ganeti/os, so you can just run:: |
24 |
|
25 |
./configure -prefix=/usr --localstatedir=/var \ |
26 |
--sysconfdir=/etc |
27 |
make && make install |
28 |
|
29 |
Note that you need to repeat this procedure on all nodes of the cluster. |
30 |
|
31 |
The actual path that ganeti has been installed with can be determined by |
32 |
looking for a file named _autoconf.py under a ganeti directory in the |
33 |
python modules tree (e.g. |
34 |
``/usr/lib/python2.4/site-packages/ganeti/_autoconf.py``). In this file, |
35 |
a variable named OS_SEARCH_PATH will list all the directories in which |
36 |
ganeti will look for OS definitions. |
37 |
|
38 |
Configuration of instance creation |
39 |
---------------------------------- |
40 |
|
41 |
The kind of instance created can be customized via a settings file. This |
42 |
file is not installed by default, as the instance creation will work |
43 |
without it. The creation scripts will look for it in |
44 |
``$sysconfdir/default/ganeti-instance-debootstrap``, so if you have run |
45 |
configure with the parameter ``--sysconfdir=/etc``, the final filename |
46 |
will be ``/etc/default/ganeti-instance-debootstrap``. |
47 |
|
48 |
The following settings will be examined in this file (see also the file |
49 |
named 'defaults' in the source distribution for more details): |
50 |
|
51 |
- PROXY: http proxy to use for non-cached installs |
52 |
- MIRROR: the mirror to use if not the default one |
53 |
- ARCH: either i386 or amd64, otherwise your current architecture will |
54 |
be used |
55 |
- SUITE: the actual OS to be installed; the current default is Debian |
56 |
*lenny*, and you can choose any of the OSes supported deboostrap (on |
57 |
Debian, look into /usr/share/deboostrap/scripts) |
58 |
- EXTRAPKGS: most OSes will need some extra packages installed to make |
59 |
them work nicely under Xen; the example file containts a few |
60 |
suggestions |
61 |
- CUSTOMIZE_DIR: a directory containing customization script for the instance. |
62 |
(by default $sysconfdir/ganeti/instance-debootstrap.d) See "Customization of |
63 |
the instance" below. |
64 |
- GENERATE_CACHE: if 'yes' (the default), the installation process will |
65 |
save and reuse a cache file to speed reinstalls (located under |
66 |
$localstatedir/cache/ganeti-instance-debootstrap) |
67 |
- CLEAN_CACHE: if empty, the cached files will never be cleaned and thus |
68 |
the installation will definitely need to be updated after install; |
69 |
otherwise, the value of this variable will be taken as the number of |
70 |
days after which to remove the cache file; the default is 14 (two |
71 |
weeks) |
72 |
- PARTITION_STYLE: if 'none' the device will be formatted directly, if 'msdos' |
73 |
a partition table will be installed on it. You need to have kpartx installed |
74 |
to use the 'msdos' option. The default is 'msdos' from Ganeti 2.0 onwards, |
75 |
but still 'none' if installing under Ganeti 1.2 |
76 |
|
77 |
Note that the settings file is important on the node that the instance |
78 |
is installed on, not the cluster master. This is indeed not a very good |
79 |
model of using this OS but currently the OS interface in ganeti is |
80 |
limiting. |
81 |
|
82 |
Customization of the instance |
83 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
84 |
|
85 |
If run-parts is in the os create script, and the CUSTOMIZE_DIR (by default |
86 |
$sysconfdir/ganeti/instance-debootstrap.d, /etc/ganeti/instance-debootstrap.d |
87 |
if you configured the os with --sysconfdir=/etc) directory exists any |
88 |
executable whose name matches the run-parts execution rules (quoting |
89 |
run-parts(8): the names must consist entirely of upper and lower case |
90 |
letters, digits, underscores, and hyphens) is executed to allow further |
91 |
personalization of the installation. The following environment variables are |
92 |
passed, in addition to the ones ganeti passes to the OS scripts: |
93 |
|
94 |
TARGET: directory in which the filesystem is mounted |
95 |
SUITE: suite installed by debootstrap (eg: lenny) |
96 |
ARCH: target architecture |
97 |
PARTITION_STYLE: style of the disk partitioning (see above) |
98 |
EXTRA_PKGS: extra packages installed by debootstrap |
99 |
BLOCKDEV: ganeti block device |
100 |
FSYSDEV: device in which the filesystem resides (the one mounted in TARGET) |
101 |
|
102 |
The scripts in CUSTOMIZE_DIR can exit with an error code to signal an error in |
103 |
the instance creation, should they fail. |
104 |
|
105 |
The scripts in CUSTOMIZE_DIR should not start any long-term processes or |
106 |
daemons using this directory, otherwise the installation will fail because it |
107 |
won't be able to umount the filesystem from the directory, and hand the |
108 |
instance back to Ganeti. |
109 |
|
110 |
|
111 |
Caching |
112 |
~~~~~~~ |
113 |
|
114 |
As described above, the install process uses a cache file in order to |
115 |
speed up repeated installs. If you only rarely do installs, this will |
116 |
not matter to you, but if you want to install 10 instances in a row, the |
117 |
difference will be visible. |
118 |
|
119 |
The default settings are to generate a cache, and to clean it up after |
120 |
two weeks. |
121 |
|
122 |
Note that the cache will use one file per architecture per suite, so if |
123 |
you install multiple suites there might be a non-trivial amount of space |
124 |
used in the cache directory. It is safe to remove manually the files. |
125 |
|
126 |
It is also possible, if done with care, to modify and regenerate the |
127 |
cache file (which is simply a tar archive) in order to preseed your |
128 |
installs with site-specific customizations. |
129 |
|
130 |
Instance notes |
131 |
-------------- |
132 |
|
133 |
The instance is a minimal install: |
134 |
|
135 |
- it has no password for root; simply login at the console |
136 |
- it has no network interfaces defined (besides lo); add your own |
137 |
definitions to /etc/network/interfaces |
138 |
- after configuring the network, it is recommended to run ``apt-get |
139 |
update`` so that signatures for the release files are picked up |