/[gentoo]/xml/htdocs/doc/en/xen-guide.xml
Gentoo

Contents of /xml/htdocs/doc/en/xen-guide.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.9 - (hide annotations) (download) (as text)
Tue Jun 7 09:27:59 2011 UTC (3 years, 6 months ago) by nightmorph
Branch: MAIN
Changes since 1.8: +6 -6 lines
File MIME type: application/xml
update URIs, bug 369837, thanks to swift for the patch

1 swift 1.1 <?xml version='1.0' encoding='UTF-8'?>
2     <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3 nightmorph 1.9 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/xen-guide.xml,v 1.8 2011/03/02 09:22:44 nightmorph Exp $ -->
4 swift 1.1
5 nightmorph 1.6 <guide>
6 swift 1.1 <title>Configuring Gentoo with Xen</title>
7    
8     <author title="Author">
9     <mail link="swift@gentoo.org">Sven Vermeulen</mail>
10     </author>
11 nightmorph 1.7 <author title="Editor">
12     <mail link="nightmorph"/>
13     </author>
14 swift 1.1
15     <abstract>
16     This guide describes how to start using Xen on your Gentoo system
17     </abstract>
18    
19     <!-- The content of this document is licensed under the CC-BY-SA license -->
20     <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
21     <license/>
22    
23 nightmorph 1.9 <version>5</version>
24     <date>2011-06-07</date>
25 swift 1.1
26     <chapter>
27     <title>Introduction</title>
28     <section>
29     <body>
30    
31     <p>
32     The <uri link="http://www.xensource.com/">Xen</uri> technology allows you to run
33     multiple operating systems on a single physical system, govern resource
34     consumption and even migrate domains (which are the virtual environments in
35     which a guest operating system runs) from one Xen-powered system to another. Xen
36     requires the host operating system to support Xen (which, in this case, will be
37     a Linux kernel) but guest operating systems can run unmodified <e>if</e> your
38     hardware supports Intel Virtualization Technology (VT-x) or AMD Virtualization
39     Technology (SVM). Otherwise your guest operating systems must also support Xen.
40     </p>
41    
42     <p>
43     This guide will talk you through the configuration steps necessary to get Xen up
44     and running on Gentoo Linux. We will not discuss Xen itself (the Xen project has
45     <uri
46     link="http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user">decent
47     documentation</uri> available) nor will we talk about specialized setups that
48     might be very interesting for Xen setups but are not Xen-related (like exporting
49     Portage through NFS, booting Linux using PXE, etc.)
50     </p>
51    
52     </body>
53     </section>
54     </chapter>
55     <chapter>
56     <title>Preparing Domain0</title>
57     <section>
58     <title>Introduction</title>
59     <body>
60    
61     <p>
62     <e>Domain0</e> is the primary domain under Xen, hosting the host operating
63     system which governs all other domains. In this chapter we will prepare an
64     existing Gentoo installation to become the host operating system in this domain
65     and build the Xen-powered kernel so that Gentoo is ready to host other Xen
66     domains.
67     </p>
68    
69     </body>
70     </section>
71     <section>
72 nightmorph 1.7 <title>Rebuilding the Gentoo Installation?</title>
73 swift 1.1 <body>
74    
75     <p>
76     A dramatic change that might be necessary is to rebuild the entire Gentoo
77     installation with a different <c>CFLAGS</c> setting. Guest operating systems
78     running under Xen might otherwise see major performance degradation. If you,
79     however, are planning on checking out Xen rather than installing it for
80     production use and are not terribly fond of rebuilding all programs, you can
81     skip this step. In this case you will notice performance degradation but you
82     will still be able to use Xen.
83     </p>
84    
85     <impo>
86     It is advised that, if you change your <c>CFLAGS</c> and build your system with
87     a gcc lower than version 4, you do not have <c>-Os</c> set as it has been
88     reported to produce broken code.
89     </impo>
90    
91     <pre caption="Editing the CFLAGS and rebuild the Gentoo installation">
92     ~# <i>nano -w /etc/make.conf</i>
93 nightmorph 1.7 <comment>(Add -mno-tls-direct-seg-refs ONLY if you have a 32-bit dom0)</comment>
94     <comment>(You don't need this flag if you have a 64-bit dom0)</comment>
95 swift 1.1 CFLAGS="-O2 -march=pentium4 -pipe <i>-mno-tls-direct-seg-refs</i>"
96    
97     ~# <i>emerge -e world</i>
98     </pre>
99    
100     <p>
101     If you boot your system using an initial ramdisk (initrd) you need to
102     rebuild the initrd as well (which is best done by running all steps you would do
103     when you rebuild your kernel).
104     </p>
105    
106     </body>
107     </section>
108     <section>
109     <title>Installing Xen</title>
110     <body>
111    
112     <p>
113 nightmorph 1.8 Xen actually contains many components, so you'll need to install a few
114     packages.
115 swift 1.1 </p>
116    
117 nightmorph 1.8 <pre caption="Installing Xen">
118 swift 1.1 ~# <i>emerge xen xen-tools xen-sources</i>
119     </pre>
120    
121     </body>
122     </section>
123     <section>
124     <title>Building the Kernel</title>
125     <body>
126    
127     <p>
128     Next we'll build the Linux kernel with Xen support. This kernel, whose sources
129     are available at <path>/usr/src/linux-2.6.x.z-xen</path>, will be our main
130     running kernel (i.e. the one running domain 0). In the <c>XEN</c> section you'll
131     find drivers for all kinds of input/output, each driver having a <e>backend</e>
132     and <e>frontend</e> implementation available. For the domain 0 kernel you need
133     to select the <e>backend</e> implementation: these are used by the other
134     domains (who use the <e>frontend</e> drivers) to communicate directly with
135     the hardware.
136     </p>
137    
138     <p>
139     Of course, don't forget to select <c>Xen-compatible</c> at <c>Processor type and
140     features</c>. If you're wondering about networking: each interface in a domain
141     has a point-to-point link to an interface on domain 0 (called
142     <path>vifX.Y</path> where X is the domain number and Y the Yth interface of that
143     domain), so you can configure your network the way you want (bridging, NAT,
144     etc.)
145     </p>
146    
147     <pre caption="Enabling Xen Support for i386 Kernels">
148     Processor type and features ---&gt;
149     Subarchitecture Type (Xen-compatible)
150     </pre>
151    
152     <pre caption="Enabling Xen Support for x86_64 Kernels">
153     Processor type and features ---&gt;
154     Subarchitecture Type (PC-compatible)
155     [*] Enable Xen compatible kernel
156 nightmorph 1.6 [*] Support for hot-pluggable CPUs
157 swift 1.1 </pre>
158    
159     <pre caption="Domain-0 Kernel Config">
160     Bus options (PCI etc.) ---&gt;
161     [*] PCI support
162 swift 1.3 [ ] Xen PCI Frontend Debugging
163 swift 1.1
164     Networking ---&gt;
165     Networking options ---&gt;
166     &lt;*&gt; 802.1d Ethernet Bridging
167     <comment>Only required by bridged networking.</comment>
168    
169     XEN ---&gt;
170     [*] Privileged Guest (domain 0)
171     &lt;*&gt; Backend driver support
172     &lt;*&gt; Block-device backend driver
173     &lt;*&gt; Network-device backend driver
174 swift 1.3 &lt;*&gt; PCI-device backend driver
175     PCI Backend Mode (Virtual PCI) ---&gt;
176 swift 1.1 [*] Scrub memory before freeing it to Xen
177     [*] Disable serial port drivers
178     Xen version compatibility (3.0.4 and later)
179     </pre>
180    
181     <pre caption="Domain-U Kernel Config">
182     Bus options (PCI etc.) ---&gt;
183     [ ] PCI support
184    
185     Device Drivers ---&gt;
186     SCSI device support ---&gt;
187     &lt; &gt; SCSI device support
188     <comment>Disabling SCSI support frees up the /dev/sd* device names
189     for use as Xen virtual block devices.</comment>
190    
191     XEN ---&gt;
192     [ ] Privileged Guest (domain 0)
193     &lt;*&gt; Block-device frontend driver
194     &lt;*&gt; Network-device frontend driver
195     [*] Scrub memory before freeing it to Xen
196     [*] Disable serial port drivers
197     Xen version compatibility (3.0.4 and later)
198     </pre>
199    
200     <p>
201     A nice hint is to have the kernel make process store its intermediate object
202     files elsewhere so that you can reuse the same kernel tree to build different
203     configurations:
204     </p>
205    
206     <pre caption="Building the Kernel">
207     ~# <i>mkdir -p ~/build/dom0 ~/build/domU</i>
208     ~# <i>make O=~/build/dom0 menuconfig</i>
209     <comment>(Configure the kernel)</comment>
210     ~# <i>make O=~/build/dom0 &amp;&amp; make O=~/build/dom0 modules_install</i>
211     </pre>
212    
213     <p>
214     Once the kernel is built you'll find the kernel image immediately in the
215     build directory (not inside <path>arch/</path> or any other directory) called
216     <path>vmlinuz</path>. Copy it to <path>/boot</path> and then configure your
217     bootloader to use the Xen hypervisor (one of the components installed
218     previously) which is stored as <path>/boot/xen.gz</path>. In the bootloader
219     configuration, add your newly built kernel as the kernel that Xen should
220     boot. For instance, for GRUB:
221     </p>
222    
223     <pre caption="GRUB Configuration for Xen">
224     title Xen 3.0 / Gentoo Linux 2.6.x.y
225     root (hd0,0)
226     kernel /boot/xen.gz
227     module /boot/kernel-2.6.x.y-xen0 root=/dev/hda3
228     </pre>
229    
230     <p>
231     Now reboot your system into Xen. Once you are booted, you need to load the Xen
232     daemon:
233     </p>
234    
235     <pre caption="Loading the Xen daemon">
236     ~# <i>/etc/init.d/xend start</i>
237     </pre>
238    
239     <p>
240     Now check if you can do whatever you normally do on your system. If this is the
241     case, you can edit your bootloader configuration to always boot into Xen and add
242     the Xen deamon to the default runlevel so that it is started automatically
243     next time you boot.
244     </p>
245    
246     <note>
247     If you wish to start guest domains automatically on boot add <c>xendomains</c>
248     to the default runlevel as well and create a symlink in
249     <path>/etc/xen/auto/</path> to the Xen configuration files for the domains
250     you wish to start.
251     </note>
252    
253     </body>
254     </section>
255     </chapter>
256     <chapter>
257     <title>Creating an Unpriviledged Domain</title>
258     <section>
259     <title>Building the Kernel</title>
260     <body>
261    
262     <p>
263     Go to the Xen-powered Linux kernel source and update the configuration. It is
264     wise to keep as many topics as possible similar to the main kernel except the
265     <c>XEN</c> settings where drivers should now have their <e>frontend</e>
266     implementation selected instead of the <e>backend</e>. Then build the kernel
267     and place the resulting <path>vmlinuz</path> file where you want (we assume this
268     is <path>/mnt/data/xen/kernel</path>):
269     </p>
270    
271     <pre caption="Building the guest kernel">
272     ~# <i>make O=~/build/domU</i>
273 cam 1.4 ~# <i>cp ~/build/domU/vmlinuz /mnt/data/xen/kernel/kernel-2.6.x.y-xen</i>
274 swift 1.1 </pre>
275    
276     <p>
277     It is also possible to create a single kernel image for both the administrative
278     domain and the unpriviledged domain. More information about this can be found
279     in the Xen user manual.
280     </p>
281    
282     </body>
283     </section>
284     <section>
285     <title>Creating the Domain Disks</title>
286     <body>
287    
288     <p>
289     For best performance, it is best to dedicate a partition (or logical volume) to
290     a domain rather than a file based filesystem. However, if you are going to use
291     Xen primarily for tests using a file based filesystem does have its advantages
292     (especially regarding maintenance).
293     </p>
294    
295     <p>
296     You can create a file based filesystem using <c>dd</c> and <c>mke2fs</c> (or
297     any other file system creation tool). For instance, to create a 2Gbyte ext3
298     filesystem:
299     </p>
300    
301     <pre caption="Creating a file based filesystem">
302     ~# <i>dd if=/dev/zero of=/mnt/data/xen/disks/ext3root.img bs=1M count=2048</i>
303     ~# <i>mke2fs -j /mnt/data/xen/disks/ext3root.img</i>
304     </pre>
305    
306     </body>
307     </section>
308     <section>
309     <title>Configuring a Domain</title>
310     <body>
311    
312     <p>
313     Next we create a Xen configuration file for a domain. You can store these
314     configuration files where you want, for instance at
315     <path>/mnt/data/xen/configs</path>. As an example, we create a configuration
316     file for a small Gentoo environment which uses the disk image we created
317     previously:
318     </p>
319    
320     <pre caption="Creating a domain configuration file">
321     ~# <i>nano -w /mnt/data/xen/configs/gentoo</i>
322    
323     kernel = "/mnt/data/xen/kernel/kernel-2.6.x.y-xen"
324     memory = 512
325     name = "gentoo"
326     <comment>(Map the disk image to the virtual /dev/sda1)</comment>
327     disk = ['file:/mnt/data/xen/disks/ext3root.img,sda1,w']
328     root = "/dev/sda1 ro"
329     </pre>
330    
331     <p>
332     If you are using a block device (such as an lvm volume or partition) for
333     the disk use 'phy:' instead of 'file:' and leave off /dev. For example:
334     </p>
335    
336     <pre caption="Using a block device">
337     <comment>(LVM Volume)</comment>
338     disk = [ 'phy:lvm/xen-guest-root,sda1,w' ]
339    
340     <comment>(Physical Partition)</comment>
341     disk = [ 'phy:sdb6,sda1,w' ]
342     </pre>
343    
344     <p>
345     You can find example configuration files in <path>/etc/xen</path>.
346     </p>
347    
348     </body>
349     </section>
350     <section>
351     <title>Launching the New Domain</title>
352     <body>
353    
354     <p>
355     Now we're all set and we can launch the new domain. If the disk image contained
356     an operating system, we could just create and attach the domain using the
357     <c>xm</c> command (Xen manager):
358     </p>
359    
360     <pre caption="Creating and starting a new domain">
361     ~# <i>xm create /mnt/data/xen/configs/gentoo -c</i>
362     </pre>
363    
364     <p>
365     The domain would be booted inside the terminal in which you executed the
366     command. However, in our case, the disk image is empty so the domain won't boot
367     up in anything useful. To fix this, you can loop-mount the image and install
368     Gentoo as you're used to.
369     </p>
370    
371     <p>
372     If you want to disconnect from the domain, press <path>Ctrl+]</path>. You can
373     always reconnect to the domains' console using <c>xm console gentoo</c>.
374     However, there is only one console per domain, so only use it when you can't
375     access the domain otherwise (for instance, through SSH).
376     </p>
377    
378     </body>
379     </section>
380     </chapter>
381     <chapter>
382     <title>Networking on Unpriviledged Domains</title>
383     <section>
384     <title>Introduction</title>
385     <body>
386    
387     <p>
388     Xen supports at least two ways of configuring your (virtual) network:
389     <e>routed</e> and <e>bridged</e>.
390     </p>
391    
392     <p>
393     When selecting the <e>routed</e> approach, the interface inside your
394     unpriviledged domain is connected to the virtual interface on your
395     administrative domain. On your administrative domain (domain 0), the virtual
396     interface is linked together with <path>eth0</path>. The
397     interface inside your unpriviledged domain should have an IP address on the same
398     network as the interface on the administrative domain. Any communication to
399     that IP address can only occur from the administrative domain, unless you set
400     up specific routing rules.
401     </p>
402    
403     <p>
404     When selecting the <e>bridged</e> approach, your default network interface on
405     the administrative domain becomes a bridge which accepts connections to the
406     virtual domains as well as to the IP address your administrative domain has.
407     </p>
408    
409     </body>
410     </section>
411     <section>
412     <title>Regular Routed Interfaces</title>
413     <body>
414    
415     <p>
416     Before you set up the interface on your unpriviledged domain, make sure that
417     Xen's <path>netloop</path> and <path>netbk</path> drivers are loaded. A quick
418     hint: if you have <path>netloop</path> as a module, load it with
419     <c>nloopbacks=0</c> so that it doesn't create pointless interfaces to the
420     loopback device. Then, edit your domain configuration file and add a <c>vif</c>
421     instruction to it.
422     </p>
423    
424     <pre caption="Configuring a virtual interface">
425     ~# <i>nano -w /mnt/data/xen/configs/gentoo</i>
426    
427     <comment>(Add the vif instruction)</comment>
428     vif = [ 'ip=192.168.1.101, vifname=veth1' ]
429     </pre>
430    
431     <p>
432     In the above example, the interface will be created for the unpriviledged domain
433     (in which it will be called <path>eth0</path>) and Xen will ensure that address
434     192.168.1.101 will be reachable from the administrative domain through interface
435     <path>veth1</path>.
436     </p>
437    
438     <p>
439     This doesn't mean that the virtual <path>eth0</path> interface will
440     automatically have IP 192.168.1.101 assigned to it, but rather that, if you
441     don't give it that IP, it will not be connected with the administrative domain
442     and thus cannot be reached.
443     </p>
444    
445     <p>
446 swift 1.5 Now edit <path>/etc/xen/xend-config.sxp</path> as follows to select routed
447 swift 1.1 network configuration:
448     </p>
449    
450 swift 1.5 <pre caption="Editing xend-config.sxp">
451     ~# <i>nano -w /etc/xen/xend-config.sxp</i>
452 swift 1.1
453     <comment>(Comment out the following lines)</comment>
454     <i>#</i>(network-script network-bridge)
455     <i>#</i>(vif-script vif-bridge)
456    
457     <comment>(Enable the following lines)</comment>
458     (network-script network-route)
459     (vif-script vif-route)
460     </pre>
461    
462     </body>
463     </section>
464     <section>
465     <title>Bridged Interfaces</title>
466     <body>
467    
468     <p>
469     Unlike the routed interfaces you now need to load the <path>netloop</path>
470     driver with <c>nloopbacks=1</c> (or higher) as the additional loopback devices
471     are used to create the bridge. For the other modules you still need the
472     <path>netbk</path> module as well as briding functionality (<path>bridge</path>
473     module if build as such).
474     </p>
475    
476     <p>
477     Now edit your virtual domain and add the <c>vif</c> construct:
478     </p>
479    
480     <pre caption="Configuring a virtual interface">
481     ~# <i>nano -w /mnt/data/xen/configs/gentoo</i>
482    
483     <comment>(Add the vif instruction)</comment>
484     vif = [ 'ip=192.168.1.101, vifname=veth0' ]
485     </pre>
486    
487     <p>
488 swift 1.5 Next edit <path>/etc/xen/xend-config.sxp</path> as follows to select bridged
489 swift 1.1 network configuration:
490     </p>
491    
492 swift 1.5 <pre caption="Editing xend-config.sxp">
493     ~# <i>nano -w /etc/xen/xend-config.sxp</i>
494 swift 1.1
495     <comment>(Enable the following lines)</comment>
496     (network-script network-bridge)
497     (vif-script vif-bridge)
498    
499     <comment>(Comment out the following lines if not done already)</comment>
500     <i>#</i> (network-script network-route)
501     <i>#</i> (vif-script vif-route)
502     </pre>
503    
504     <p>
505     By default, the bridge will contain whatever interface is configured to be the
506     default interface (the device that is listed under the default route through
507     <c>ip route list</c>). If you want to alter this behavior, edit the
508 swift 1.5 <path>xend-config.sxp</path> as follows:
509 swift 1.1 </p>
510    
511 swift 1.5 <pre caption="Editing xend-config.sxp to change bridge configuration">
512     ~# <i>nano -w /etc/xen/xend-config.sxp</i>
513 swift 1.1
514     <comment>(Edit the network-script line)</comment>
515     (network-script <i>'</i>network-bridge <i>netdev=eth0 bridge=xenbr0 vifnum=0'</i>)
516     </pre>
517    
518     <p>
519     Once the configuration is done, restart the <c>xend</c> init script to have Xen
520     build the bridge:
521     </p>
522    
523     <pre caption="Restarting the xend daemon">
524     ~# <i>/etc/init.d/xend restart</i>
525     </pre>
526    
527     </body>
528     </section>
529     </chapter>
530 swift 1.2 <chapter>
531     <title>Further Resources</title>
532     <section>
533     <title>Xen Documentation</title>
534     <body>
535    
536     <ul>
537     <li>
538 nightmorph 1.9 <uri link="http://bits.xensource.com/Xen/docs/user.pdf">Xen
539     Users' Manual (PDF)</uri>
540 swift 1.2 </li>
541     <li>
542 nightmorph 1.9 <uri link="http://www.xen.org/support/documentation.html">Xen Community
543 swift 1.2 Documentation</uri>
544     </li>
545     <li>
546     <uri link="http://wiki.xensource.com/xenwiki/">Xen Wiki</uri>
547     </li>
548     </ul>
549    
550     </body>
551     </section>
552     <section>
553     <title>Xen Tools</title>
554     <body>
555    
556     <ul>
557     <li>
558     <uri
559     link="http://virt-manager.et.redhat.com/">app-emulation/virt-manager</uri>
560     is a graphical tool for administering virtual machines
561     </li>
562     </ul>
563    
564     </body>
565     </section>
566     </chapter>
567 swift 1.1 </guide>

  ViewVC Help
Powered by ViewVC 1.1.20