]>
Commit | Line | Data |
---|---|---|
419ef454 DM |
1 | Host System Administration |
2 | ========================== | |
b7c3af6a | 3 | include::attributes.txt[] |
419ef454 DM |
4 | |
5 | {pve} is based on the famous https://www.debian.org/[Debian] Linux | |
6 | distribution. That means that you have access to the whole world of | |
7 | Debian packages, and the base system is well documented. The | |
8 | https://debian-handbook.info/download/stable/debian-handbook.pdf[Debian | |
65647b07 | 9 | Administrator\'s Handbook] is available online, and provides a |
419ef454 DM |
10 | comprehensive introduction to the Debian operating system (see |
11 | xref:Hertzog13[]). | |
12 | ||
13 | A standard {pve} installation uses the default repositories from | |
14 | Debian, so you get bug fixes and security updates through that | |
15 | channel. In addition, we provide our own package repository to roll | |
16 | out all {pve} related packages. This includes updates to some | |
17 | Debian packages when necessary. | |
18 | ||
19 | We also deliver a specially optimized Linux kernel, where we enable all | |
20 | required virtualization and container features. That kernel includes | |
21 | drivers for http://zfsonlinux.org/[ZFS], and several hardware drivers. | |
22 | For example, we ship Intel network card drivers to support their | |
23 | newest hardware. | |
24 | ||
25 | The following sections will concentrate on virtualization related | |
26 | topics. They either explains things which are different on {pve}, or | |
27 | tasks which are commonly used on {pve}. For other topics, please refer | |
28 | to the standard Debian documentation. | |
29 | ||
30 | System requirements | |
31 | ------------------- | |
32 | ||
33 | For production servers, high quality server equipment is needed. Keep | |
34 | in mind, if you run 10 Virtual Servers on one machine and you then | |
35 | experience a hardware failure, 10 services are lost. {pve} | |
36 | supports clustering, this means that multiple {pve} installations | |
37 | can be centrally managed thanks to the included cluster functionality. | |
38 | ||
39 | {pve} can use local storage (DAS), SAN, NAS and also distributed | |
40 | storage (Ceph RBD). For details see xref:chapter-storage[chapter storage]. | |
41 | ||
42 | Minimum requirements, for evaluation | |
43 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
44 | ||
45 | * CPU: 64bit (Intel EMT64 or AMD64) | |
46 | ||
47 | * RAM: 1 GB RAM | |
48 | ||
49 | * Hard drive | |
50 | ||
51 | * One NIC | |
52 | ||
53 | Recommended system requirements | |
54 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
55 | ||
56 | * CPU: 64bit (Intel EMT64 or AMD64), Multi core CPU recommended | |
57 | ||
58 | * RAM: 8 GB is good, more is better | |
59 | ||
60 | * Hardware RAID with batteries protected write cache (BBU) or flash | |
61 | based protection | |
62 | ||
63 | * Fast hard drives, best results with 15k rpm SAS, Raid10 | |
64 | ||
65 | * At least two NIC´s, depending on the used storage technology you need more | |
66 | ||
67 | ||
d91f8c1e | 68 | include::getting-help.adoc[] |
419ef454 | 69 | |
d91f8c1e | 70 | include::pve-package-repos.adoc[] |
419ef454 | 71 | |
d91f8c1e | 72 | include::pve-installation.adoc[] |
419ef454 | 73 | |
d91f8c1e | 74 | include::system-software-updates.adoc[] |
202dc350 DM |
75 | |
76 | ||
419ef454 DM |
77 | Network Configuration |
78 | --------------------- | |
79 | ||
69c356c4 DM |
80 | {pve} uses a bridged networking model. Each host can have up to 4094 |
81 | bridges. Bridges are like physical network switches implemented in | |
82 | software. All VMs can share a single bridge, as if | |
83 | virtual network cables from each guest were all plugged into the same | |
84 | switch. But you can also create multiple bridges to separate network | |
85 | domains. | |
86 | ||
87 | For connecting VMs to the outside world, bridges are attached to | |
88 | physical network cards. For further flexibility, you can configure | |
89 | VLANs (IEEE 802.1q) and network bonding, also known as "link | |
90 | aggregation". That way it is possible to build complex and flexible | |
91 | virtual networks. | |
92 | ||
93 | Debian traditionally uses the 'ifup' and 'ifdown' commands to | |
94 | configure the network. The file '/etc/network/interfaces' contains the | |
95 | whole network setup. Please refer to to manual page ('man interfaces') | |
96 | for a complete format description. | |
97 | ||
98 | NOTE: {pve} does not write changes directly to | |
99 | '/etc/network/interfaces'. Instead, we write into a temporary file | |
100 | called '/etc/network/interfaces.new', and commit those changes when | |
101 | you reboot the node. | |
102 | ||
103 | It is worth mentioning that you can directly edit the configuration | |
104 | file. All {pve} tools tries hard to keep such direct user | |
105 | modifications. Using the GUI is still preferable, because it | |
106 | protect you from errors. | |
107 | ||
108 | Naming Conventions | |
109 | ~~~~~~~~~~~~~~~~~~ | |
110 | ||
111 | We currently use the following naming conventions for device names: | |
112 | ||
113 | * Ethernet devices: eth[N], where 0 ≤ N (`eth0`, `eth1`, ...) | |
114 | ||
115 | * Bridge names: vmbr[N], where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`) | |
419ef454 | 116 | |
69c356c4 DM |
117 | * Bonds: bond[N], where 0 ≤ N (`bond0`, `bond1`, ...) |
118 | ||
119 | * VLANs: Simply add the VLAN number to the device name, | |
120 | separated by a period (`eth0.50`, `bond1.30`) | |
121 | ||
122 | This makes it easier to debug networks problems, because the device | |
123 | names implies the device type. | |
124 | ||
125 | Default Configuration using a Bridge | |
126 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
419ef454 | 127 | |
69c356c4 DM |
128 | The installation program creates a single bridge named `vmbr0`, which |
129 | is connected to the first ethernet card `eth0`. The corresponding | |
130 | configuration in '/etc/network/interfaces' looks like this: | |
131 | ||
132 | ---- | |
133 | auto lo | |
134 | iface lo inet loopback | |
135 | ||
136 | iface eth0 inet manual | |
137 | ||
138 | auto vmbr0 | |
139 | iface vmbr0 inet static | |
140 | address 192.168.10.2 | |
141 | netmask 255.255.255.0 | |
142 | gateway 192.168.10.1 | |
143 | bridge_ports eth0 | |
144 | bridge_stp off | |
145 | bridge_fd 0 | |
146 | ---- | |
147 | ||
148 | Virtual machines behave as if they were directly connected to the | |
149 | physical network. The network, in turn, sees each virtual machine as | |
150 | having its own MAC, even though there is only one network cable | |
151 | connecting all of these VMs to the network. | |
152 | ||
153 | ||
154 | Routed Configuration | |
155 | ~~~~~~~~~~~~~~~~~~~~ | |
156 | ||
157 | Most hosting providers do not support the above setup. For security | |
158 | reasons, they disable networking as soon as they detect multiple MAC | |
159 | addresses on a single interface. | |
160 | ||
161 | TIP: Some providers allows you to register additional MACs on there | |
162 | management interface. This avoids the problem, but is clumsy to | |
163 | configure because you need to register a MAC for each of your VMs. | |
164 | ||
165 | You can avoid the problem by "routing" all traffic via a single | |
166 | interface. This makes sure that all network packets use the same MAC | |
167 | address. | |
168 | ||
169 | A common scenario is that you have a public IP (assume 192.168.10.2 | |
170 | for this example), and an additional IP block for your VMs | |
171 | (10.10.10.1/255.255.255.0). We recommend the following setup for such | |
172 | situations: | |
173 | ||
174 | ---- | |
175 | auto lo | |
176 | iface lo inet loopback | |
177 | ||
178 | auto eth0 | |
179 | iface eth0 inet static | |
180 | address 192.168.10.2 | |
181 | netmask 255.255.255.0 | |
182 | gateway 192.168.10.1 | |
183 | post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp | |
184 | ||
185 | ||
186 | auto vmbr0 | |
187 | iface vmbr0 inet static | |
188 | address 10.10.10.1 | |
189 | netmask 255.255.255.0 | |
190 | bridge_ports none | |
191 | bridge_stp off | |
192 | bridge_fd 0 | |
193 | ---- | |
194 | ||
195 | ||
196 | Masquerading (NAT) with iptables | |
197 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
198 | ||
199 | In some cases you may want to use private IPs behind your Proxmox | |
200 | host's true IP, and masquerade the traffic using NAT: | |
201 | ||
202 | ---- | |
203 | auto lo | |
204 | iface lo inet loopback | |
205 | ||
206 | auto eth0 | |
207 | #real IP adress | |
208 | iface eth0 inet static | |
209 | address 192.168.10.2 | |
210 | netmask 255.255.255.0 | |
211 | gateway 192.168.10.1 | |
212 | ||
213 | auto vmbr0 | |
214 | #private sub network | |
215 | iface vmbr0 inet static | |
216 | address 10.10.10.1 | |
217 | netmask 255.255.255.0 | |
218 | bridge_ports none | |
219 | bridge_stp off | |
220 | bridge_fd 0 | |
221 | ||
222 | post-up echo 1 > /proc/sys/net/ipv4/ip_forward | |
223 | post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE | |
224 | post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE | |
225 | ---- | |
226 | ||
227 | //// | |
228 | TODO: explain IPv6 support? | |
229 | TODO: explan OVS | |
230 | //// | |
231 | ||
232 | ||
233 | //// | |
234 | TODO: | |
419ef454 DM |
235 | |
236 | Local Storage | |
237 | ------------- | |
238 | ||
239 | Logical Volume Manager (LVM) | |
240 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
241 | ||
650c5cc1 | 242 | TODO: info about LVM. |
419ef454 DM |
243 | |
244 | ||
245 | ZFS on Linux | |
246 | ~~~~~~~~~~~~ | |
247 | ||
650c5cc1 | 248 | TODO: info about ZFS. |
419ef454 DM |
249 | |
250 | ||
251 | Working with 'systemd' | |
252 | ---------------------- | |
253 | ||
254 | Journal and syslog | |
255 | ~~~~~~~~~~~~~~~~~~ | |
256 | ||
257 | TODO: explain persistent journal... | |
258 | ||
259 | ||
69c356c4 | 260 | //// |
419ef454 DM |
261 | |
262 | ||
263 | ||
264 | ||
265 |