https://wiki.xenproject.org/api.php?action=feedcontributions&user=7heo&feedformat=atomXen - User contributions [en]2024-03-29T11:31:52ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=PvGrub&diff=7867PvGrub2013-05-17T18:25:51Z<p>7heo: /* Notes */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
See [[#Tips|Troubleshooting/Tips]].<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
== Tips ==<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Links ==<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html GNU GRUB Manual 0.97]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html#Command_002dline-and-menu-entry-commands The list of command-line and menu entry commands]<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7866PvGrub2013-05-17T18:24:58Z<p>7heo: /* Troubleshooting */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
See [[#Troubleshooting]].<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
== Tips ==<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Links ==<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html GNU GRUB Manual 0.97]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html#Command_002dline-and-menu-entry-commands The list of command-line and menu entry commands]<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7865PvGrub2013-05-17T18:24:31Z<p>7heo: /* Notes */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
See [[#Troubleshooting]].<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html GNU GRUB Manual 0.97]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html#Command_002dline-and-menu-entry-commands The list of command-line and menu entry commands]<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7864PvGrub2013-05-17T18:22:54Z<p>7heo: /* Troubleshooting */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html GNU GRUB Manual 0.97]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html#Command_002dline-and-menu-entry-commands The list of command-line and menu entry commands]<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7863PvGrub2013-05-17T18:22:27Z<p>7heo: /* Troubleshooting */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html|GNU GRUB Manual 0.97]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html#Command_002dline-and-menu-entry-commands|The list of command-line and menu entry commands]<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7862PvGrub2013-05-17T18:18:01Z<p>7heo: /* References */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= Troubleshooting =<br />
<br />
Since pvgrub corresponds to GRUB legacy, it is not supported anymore by the GRUB developers. Until there is a pvgrub2, one should use the following resources to get help and solve problems:<br />
* [[pvgrub console help]]<br />
* [http://www.gnu.org/software/grub/manual/legacy/grub.html|GNU GRUB Manual 0.97]<br />
<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7861PvGrub2013-05-17T18:13:10Z<p>7heo: /* Notes */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
* The content of the usual <code>root</code> parameter of the DomU configuration file should be appended to the <code>kernel</code> line in the <code>menu.lst</code> file; in the DomU file system.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7860PvGrub2013-05-17T18:12:00Z<p>7heo: /* Notes */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
* There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7859PvGrub2013-05-17T18:11:32Z<p>7heo: /* Configure */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
=== Notes ===<br />
<br />
- There shall be no <code>root</code> parameter in the DomU configuration file if you use pvgrub. If there is one, it will likely be prepended to the <code>cmdline</code>; rendering the <code>extra</code> inoperant. In this case, you will be dropped to a grub shell instead of having a grub menu.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7858PvGrub2013-05-17T18:07:12Z<p>7heo: /* Configure */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
=== Boot domU from local disk ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
This example is assuming that you have a boot partition (mounted at <code>/boot</code> in your <code>/etc/fstab</code>) as the first partition of the first hard drive; and that this partition contains a <code>grub</code> directory containing a <code>menu.lst</code> file.<br />
<br />
=== Boot domU from network ===<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7635Compiling Xen From Source on NetBSD2013-04-29T12:43:09Z<p>7heo: /* Cloning */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Note: you can find a list of the available branches and how to obtain them [[Xen_Repositories|here]].<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
{{info|Note: For PAE-enabled xen.gz ELFs, there are also PAE kernels in the binary/kernel directory of your <version>/<architecture> setup on the netbsd ftp.}}<br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=pc;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7634Compiling Xen From Source on NetBSD2013-04-29T12:41:41Z<p>7heo: /* Cloning */ Remove the big list of branches/tags</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Note: you can find a list of the available branches and how to obtain them [[Xen_Repositories|here]]<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
{{info|Note: For PAE-enabled xen.gz ELFs, there are also PAE kernels in the binary/kernel directory of your <version>/<architecture> setup on the netbsd ftp.}}<br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=pc;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7579PvGrub2013-04-27T10:31:34Z<p>7heo: /* Build */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen, for the <code>bits/predefs.h</code> file):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7578PvGrub2013-04-27T10:30:44Z<p>7heo: /* Build */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
<br />
you might also lack the following package (dependency for some versions of Xen):<br />
<br />
libc6-dev-i386<br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7576Compiling Xen From Source on NetBSD2013-04-26T09:43:16Z<p>7heo: /* Install */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
{{info|Note: For PAE-enabled xen.gz ELFs, there are also PAE kernels in the binary/kernel directory of your <version>/<architecture> setup on the netbsd ftp.}}<br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=pc;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7575Compiling Xen From Source on NetBSD2013-04-26T09:42:46Z<p>7heo: </p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Note: For PAE-enabled xen.gz ELFs, there are also PAE kernels in the binary/kernel directory of your <version>/<architecture> setup on the netbsd ftp.<br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=pc;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7574Compiling Xen From Source on NetBSD2013-04-26T09:37:01Z<p>7heo: /* Install */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=pc;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7573Compiling Xen From Source on NetBSD2013-04-26T09:36:00Z<p>7heo: restored one pre tag to remove an unwanted link.</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7554Compiling Xen From Source on NetBSD2013-04-25T10:59:11Z<p>7heo: Replacing pre tags by indentation.</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
shell/bash<br />
devel/pkg-config<br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
# cp xen/xen.gz /xen.gz<br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
<br />
For a serial console boot use the following:<br />
<br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
# gmake install-tools<br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
# shutdown -r now<br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<br />
devel/yajl<br />
<br />
Check that xl is working:<br />
<br />
# xl list<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7553Compiling Xen From Source on NetBSD2013-04-25T10:52:11Z<p>7heo: /* Cloning */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
<pre><br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
</pre><br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
Note: For the sake of brevity, many versions are listed using {n..m}, n being the lower limit, m being the higher one.<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
devel/yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7552Compiling Xen From Source on NetBSD2013-04-25T10:49:37Z<p>7heo: </p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Cloning==<br />
<br />
To clone the repository with git, use:<br />
<br />
<pre><br />
git clone -b <BRANCH> git://xenbits.xen.org/xen<br />
</pre><br />
<br />
Where branch is one of the following (-b accepts branches as well as tags):<br />
<br />
* Tags (advised, they are like detached heads)<br />
** Releases<br />
*** RELEASE-4.2.{0..2}<br />
*** RELEASE-4.1.{0..5}<br />
*** RELEASE-4.0.{0..4}<br />
*** RELEASE-3.0.0<br />
*** RELEASE-2.0.{0..6}<br />
** Release candidates<br />
*** 4.2.2-rc{1..2}<br />
*** 4.2.1-rc{1..2}<br />
*** 4.2.0-rc{1..5}<br />
*** 4.1.5-rc{1..2}<br />
*** 4.1.4-rc{1..2}<br />
*** 4.1.3-rc{1..3}<br />
*** 4.1.2-rc{1..3}<br />
*** 4.1.1-rc{1..2}<br />
*** 4.1.0-rc{1..8}<br />
*** 4.0.4-rc{1..3}<br />
*** 4.0.3-rc{1..3}<br />
*** 4.0.2-rc{3..6}<br />
*** 4.0.1-rc{1..6}<br />
*** 4.0.0-rc{1..9}<br />
*** 3.3.0-rc{1..7}<br />
*** 3.2.0-rc{1..6}<br />
*** 3.0.2-rc<br />
** Branched<br />
*** 4.2.0-branched<br />
*** 4.1.0-branched<br />
*** 4.0.0-branched<br />
*** 3.3.0-branched<br />
*** 3.1.0-branched<br />
*** 3.0.4-branched<br />
*** 3.0.3-branched<br />
*** 3.0.2-branched<br />
** Misc<br />
*** sparse-tree-deprecated<br />
*** ia64-stable<br />
*** semistable<br />
*** latest-semistable<br />
*** latest-stable<br />
*** split-1.1<br />
*** split-1.0<br />
*** beta1<br />
* Branches (not advised, unless if you want to contribute)<br />
** master (or HEAD)<br />
** stable-4.0<br />
** stable-4.1<br />
** stable-4.2<br />
** staging<br />
** staging-4.0<br />
** staging-4.1<br />
** staging-4.2<br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
devel/yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7551Compiling Xen From Source on NetBSD2013-04-25T09:56:18Z<p>7heo: /* Dependencies */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py27-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
devel/yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7529Compiling Xen From Source on NetBSD2013-04-21T20:46:19Z<p>7heo: </p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
devel/yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7528Compiling Xen From Source on NetBSD2013-04-21T20:43:56Z<p>7heo: /* Basic usage */ typo</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang indefinitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7527Compiling Xen From Source on NetBSD2013-04-21T20:37:03Z<p>7heo: /* Basic usage */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
{{warning|If the directory <code>/var/lib/xenstored</code> is missing, both the xencommons script and the tools will hang definitely. Please check that this directory exists before proceeding further.}}<br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7526Compiling Xen From Source on NetBSD2013-04-21T19:42:44Z<p>7heo: /* Basic usage */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
If you built xen onto another system, runtime dependencies are required:<br />
<pre><br />
yajl<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7525Compiling Xen From Source on NetBSD2013-04-20T22:55:56Z<p>7heo: /* Dependencies */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkg-config<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7524Compiling Xen From Source on NetBSD2013-04-20T22:46:55Z<p>7heo: /* Dependencies */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkgconfig<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7523Compiling Xen From Source on NetBSD2013-04-20T22:43:15Z<p>7heo: /* Dependencies */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source|pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
devel/pkgconfig<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source_on_NetBSD&diff=7522Compiling Xen From Source on NetBSD2013-04-20T22:35:16Z<p>7heo: /* Dependencies */</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen 4.2 release, which is the first release to build natively on NetBSD without any specific patches.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Dependencies==<br />
<br />
The first step is to install the dependencies needed by Xen, they can all be found in pkgsrc. Here is the list of packages that should be installed for 4.2:<br />
<br />
<pre><br />
devel/mercurial<br />
devel/scmgit<br />
devel/gmake<br />
lang/python27<br />
devel/py-curses<br />
devel/dev86<br />
devel/glib2<br />
devel/yajl<br />
</pre><br />
<br />
If you followed the [http://www.netbsd.org/docs/pkgsrc/using.html#building-packages-from-source|pkgsrc instructions for building from source], and didn't install anything aside from the minimal selection of sets, the <code>comp</code> and the <code>text</code> sets, you also have to install:<br />
<br />
<pre><br />
shell/bash<br />
</pre><br />
<br />
==Configuration==<br />
<br />
From Xen 4.2 onwards Xen uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen, as well as compile time sanity checking. Since pkgsrc installs packages in /usr/pkg, we will need to instruct configure to search for the required libraries there:<br />
<br />
<pre><br />
$ ./configure PYTHON=/usr/pkg/bin/python2.7 APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib --prefix=/usr/xen42<br />
</pre><br />
<br />
Please note that "prefix" has been set to /usr/xen42, you can change this to install it in /usr/pkg or whatever directory that suits your needs.<br />
<br />
==Building==<br />
<br />
Now that the configuration has finished, let's start the building. Stubdomains are not available on NetBSD, so we will skip the build of those:<br />
<br />
<pre><br />
$ gmake PYTHON=/usr/pkg/bin/python2.7 xen<br />
$ gmake LD_LIBRARY_PATH=/usr/pkg/lib tools<br />
</pre><br />
<br />
{{Info|The Xen build system supports running several jobs at the same time, so it's recomendable to use the -jX option to speed up the build process if you have a SMP machine.}}<br />
<br />
==Install==<br />
<br />
First, we will copy the Xen kernel to /:<br />
<br />
<pre><br />
# cp xen/xen.gz /xen.gz<br />
</pre><br />
<br />
Now we need to fetch a Dom0 kernel for the NetBSD version we are running, Dom0 kernels can be found at:<br />
<br />
<pre><br />
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-<version>/<arch>/binary/kernel/netbsd-XEN3_DOM0.gz<br />
</pre><br />
<br />
Download it to /, unpack and rename it to netbsd.xen. The next step is to modify the bootloader to correctly boot the Xen kernel and NetBSD. The following line should be added to /boot.cfg:<br />
<br />
<pre><br />
menu=NetBSD Xen:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M<br />
</pre><br />
<br />
For a serial console boot use the following:<br />
<br />
<pre><br />
menu=NetBSD Xen com0:load /netbsd.xen console=com0;multiboot /xen.gz dom0_mem=512M console=com1 com1=115200,8n1<br />
</pre><br />
<br />
Also, set the dom0_mem parameter to an appropriate value for your use case. More info about the Xen kernel boot parameters can be found at [[Xen Command Line and Boot Options]].<br />
<br />
Finally, we should install the tools that we compiled previously:<br />
<br />
<pre><br />
# gmake install-tools<br />
</pre><br />
<br />
Now we can reboot into the newly installed Xen system:<br />
<br />
<pre><br />
# shutdown -r now<br />
</pre><br />
<br />
==Basic usage==<br />
<br />
If you have installed Xen in a location different than /usr/pkg you will need to add it to your LD_LIBRARY_PATH, PATH and PYTHONPATH:<br />
<br />
<pre><br />
# export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/xen42/lib"<br />
# export PATH="${PATH}:/usr/xen42/sbin:/usr/xen42/bin"<br />
# export PYTHONPATH="/usr/xen42/lib/python2.7/site-packages"<br />
</pre><br />
<br />
To begin using Xen, xencommons has to be started:<br />
<br />
<pre><br />
# /usr/xen42/etc/rc.d/xencommons onestart<br />
</pre><br />
<br />
Check that xl is working:<br />
<br />
<pre><br />
# xl list<br />
</pre><br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:NetBSD]]</div>7heohttps://wiki.xenproject.org/index.php?title=Talk:PVGrub_HowTo&diff=7481Talk:PVGrub HowTo2013-04-09T16:07:02Z<p>7heo: /* Duplicate information, could be organised better */</p>
<hr />
<div>==Duplicate information, could be organised better==<br />
<br />
There is [[PvGrub|another page]] which contains more or less a subset of the information which is on this page. Maybe it would be better to split the information in these two pages, given that it is practical information (this one) or theorical information and presentation (the one linked just before).<br />
<br />
'''Update (2013/05/09)''': Merged. See the discussion of the new page.<br />
<br />
--[[User:7heo|7heo]] 01:39, 12 February 2013 (UTC)</div>7heohttps://wiki.xenproject.org/index.php?title=Talk:PvGrub&diff=7480Talk:PvGrub2013-04-09T16:06:07Z<p>7heo: </p>
<hr />
<div>I finally merged the two pages ([[Talk:PVGrub_HowTo|ref]])<br />
<br />
-- [[User:7heo|7heo]] 16:05, 9 April 2013 (UTC)</div>7heohttps://wiki.xenproject.org/index.php?title=Talk:PvGrub&diff=7479Talk:PvGrub2013-04-09T16:05:46Z<p>7heo: Created page with "I finally merged the two pages (ref) ~~~~"</p>
<hr />
<div>I finally merged the two pages ([[Talk:PVGrub_HowTo|ref]])<br />
[[User:7heo|7heo]] 16:05, 9 April 2013 (UTC)</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7478PvGrub2013-04-09T16:03:59Z<p>7heo: /* How To */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]:<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help.<br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7477PvGrub2013-04-09T16:01:49Z<p>7heo: </p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
Inspired from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create <code>${tftproot}/grub/menu.lst</code>; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7476PvGrub2013-04-09T15:53:06Z<p>7heo: /* Technical details */</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
PVGRUB, as mentionned in the introduction, is an adapted Grub bootloader built for Xen. Since it uses the codebase of a widely used software (i.e. GRUB), it should be less prone to bugs than its older alternative, PyGrub. Also, since it is not scripted but a complied binary, it is probably more efficient and has less dependencies (at least for python). Lastly; since the bootloader is designed to run as a ParaVirtualized loader in the DomU environment rather than to perform risky operations (such as copying a file from a potentially non-trusted virtual disk on the Dom0) as PyGrub does; it is also way more secure.<br />
<br />
= How To =<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create ${tftproot}/grub/menu.lst; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7475PVGrub HowTo2013-04-09T15:40:36Z<p>7heo: Redirected page to PvGrub#How To</p>
<hr />
<div>#REDIRECT [[PvGrub#How_To]]</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7474PvGrub2013-04-09T15:38:09Z<p>7heo: Merge the howto with this page, re-structure the information, add a section about technical details, will be filled in the next commit.</p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB (ParaVirtual Grub) is a boot manager for Xen virtual machines. It is a safer (as in more reliable but specifically as in more secure - see the technical details section) and more efficient alternative to [[PyGrub]] to boot domU images: unlike pygrub it runs an adapted version of the grub boot loader inside the created domain itself, and uses the regular domU facilities to read the disk mounted as root directory, fetch files from network, etc.; it also eventually loads the PV kernel and chain-boots it.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Technical details =<br />
<br />
= How To =<br />
== Build ==<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
== Configure ==<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create ${tftproot}/grub/menu.lst; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
== Modify /etc/modprobe.conf in the guest ==<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
== Update /etc/inittab and /etc/securetty in the guest ==<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
== Install a stub grub.conf in the guest so that the grub update scripts won’t fail ==<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
== Install kernel packages in the guest ==<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
== Modify Xen guest config file in the dom0 ==<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
== Shutdown and then create the domain ==<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
= References =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
<br />
<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7473PVGrub HowTo2013-04-09T15:24:41Z<p>7heo: Redirected page to PvGrub</p>
<hr />
<div>#REDIRECT [[PvGrub]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7472PVGrub HowTo2013-04-09T15:23:48Z<p>7heo: /* Shutdown and then create the domain */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7471PVGrub HowTo2013-04-09T15:23:18Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for building pv-grub on a stock GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7470PVGrub HowTo2013-04-09T15:22:38Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as gzip archives in the <code>xen/dist/install/usr/lib/xen/boot/</code> directory<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7469PVGrub HowTo2013-04-09T15:19:35Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian 6 (squeeze)<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as mini-iso.gz archives in the build directories.<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7468PVGrub HowTo2013-04-09T15:17:07Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian<br />
<br />
<code><pre><br />
#!/bin/sh<br />
<br />
apt-get install git<br />
#for the configure checks<br />
apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
#not checked by the configure script<br />
apt-get install libpixman-1-dev bzip2<br />
git clone git://xenbits.xen.org/xen<br />
cd xen<br />
./configure<br />
make<br />
</pre></code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as mini-iso.gz archives in the build directories.<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7467PVGrub HowTo2013-04-09T15:15:03Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian<br />
<br />
<code><br />
# #!/bin/sh<br />
#<br />
# apt-get install git<br />
# #for the configure checks<br />
# apt-get install python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
# #not checked by the configure script<br />
# apt-get install libpixman-1-dev bzip2<br />
# git clone git://xenbits.xen.org/xen<br />
# cd xen<br />
# ./configure<br />
# make<br />
</code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as mini-iso.gz archives in the build directories.<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7466PVGrub HowTo2013-04-09T15:14:18Z<p>7heo: /* Build */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian<br />
<br />
<code><br />
# #for the configure checks<br />
# apt-get install git python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
# #not checked by the configure script<br />
# apt-get install libpixman-1-dev bzip2<br />
# git clone git://xenbits.xen.org/xen<br />
# cd xen<br />
# ./configure<br />
# make<br />
</code><br />
<br />
Then you can find the pv-grub in two architectures (32 and 64 bits) as mini-iso.gz archives in the build directories.<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7463PVGrub HowTo2013-04-09T15:05:26Z<p>7heo: </p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Build =<br />
The following example is for GNU/Linux Debian<br />
<br />
<code><br />
# #for the configure checks<br />
# apt-get install git python-dev gettext bin86 bcc iasl uuid-dev libncurses5-dev pkg-config libglib2.0-dev libyajl-dev<br />
# #not checked by the configure script<br />
# apt-get install libpixman-1-dev bzip2<br />
# git clone git://xenbits.xen.org/xen<br />
# cd xen<br />
# ./configure<br />
# make<br />
</code><br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PVGrub_HowTo&diff=7462PVGrub HowTo2013-04-09T15:01:02Z<p>7heo: /* Notes */</p>
<hr />
<div>Copied from [http://backdrift.org/xen-pvgrub-howto backdrift.org/xen-pvgrub-howto]<br />
<br />
So if you’re like me you are probably somewhat lazy. I imagine most sysadmins are. Which must be why we put so much effort into scripting and automating repeated tasks. If you’ve managed a Xen VM before you are likely to notice that all your kernel images live outside the VM itself. This makes it rather difficult to patch and upgrade among other things, especially as the number and type of guests you support grows. Pvgrub can help solve this problem. It implements grub in a stub domain which in turn loads your guest domain. It works quite well and is rather easy to set up. Read on to learn more.<br />
<br />
From the xen wiki: “PV-GRUB replaces PyGrub to boot domU images safely: it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it.”<br />
<br />
This means that your domU guests can install and manage their own kernels as if they were running on regular hardware. Yum, apt-get and other package management software will let you patch your virtual machine’s kernel without the need to alter any Xen configuration. Here’s how it works.<br />
<br />
= Notes =<br />
* Pvgrub requires Xen 3.3 or greater.<br />
* You won’t actually need to install grub in the domU, it is implemented as a stub domain and provided with the Xen sources.<br />
* On certain GNU/Linux distributions (Debian, for example), [http://www.gossamer-threads.com/lists/xen/users/243763#243763 the pvgrub.gz file isn't packaged]. As a result, it is not possible to directly use the pvgrub loader in these GNU/Linux distributions. As a workaround, you can build it from the sources (see build subsection).<br />
<br />
= Modify /etc/modprobe.conf in the guest =<br />
<br />
We need to make sure that a couple of lines exist in /etc/modprobe.conf before we’re ready to install the kernel packages. We add these so that when the kernel install process goes to build a new initrd it will include the correct driver modules for your hardware, so we want to be certain that the Xen block and net drivers are included.<br />
<br />
Note: If /etc/modprobe.conf doesn’t already exist you should create it.<br />
<br />
<code><pre><br />
#/etc/modprobe.conf<br />
alias eth0 xennet<br />
alias scsi_hostadapter xenblk<br />
</pre></code><br />
<br />
= Update /etc/inittab and /etc/securetty in the guest =<br />
<br />
Now we update /etc/inittab and /etc/securetty to make certain that we attach to and permit logins from the various xen consoles.<br />
<br />
/etc/inittab<br />
<code><pre><br />
#/etc/inittab<br />
hvc0:2345:respawn:/sbin/getty 38400 hvc0<br />
xvc0:2345:respawn:/sbin/getty 38400 xvc0<br />
</pre></code><br />
<br />
/etc/securetty<br />
<code><pre><br />
#/etc/securetty<br />
# hypervisor virtual consoles<br />
hvc0<br />
xvc0<br />
</pre></code><br />
<br />
= Install a stub grub.conf in the guest so that the grub update scripts won’t fail =<br />
<br />
Configuration file locations:<br />
<br />
Depending on the Linux distribution you use you’re likely to see the grub config in either /boot/grub/grub.conf or /boot/grub/menu.lst. To keep things simple I usually use /boot/grub/grub.conf as a config file and symlink /boot/grub/menu.lst to it. This should ensure that scripts used to automatically update the grub config when a new kernel is installed will work correctly.<br />
<br />
Reasonable stub for Debian Lenny<br />
<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.26-2-xen-686<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.26-2-xen-686 console=hvc0 root=/dev/xvda1 ro<br />
initrd /boot/initrd.img-2.6.26-2-xen-686<br />
</pre></code><br />
<br />
Reasonable stub for CentOS/RHEL<br />
<code><pre><br />
#/boot/grub/grub.conf<br />
default 0<br />
timeout 5<br />
<br />
title vmlinuz-2.6.18-128.4.1.el5xen<br />
root (hd0)<br />
kernel /boot/vmlinuz-2.6.18-128.4.1.el5xen root=LABEL=root ro<br />
initrd /boot/initrd-2.6.18-128.4.1.el5xen.img<br />
</pre></code><br />
<br />
= Install kernel packages in the guest =<br />
<br />
Debian<br />
<code><pre><br />
# apt-get install linux-image-2.6.26-1-686-bigmem<br />
</pre></code><br />
<br />
CentOS/RHEL<br />
<code><pre><br />
# yum install kernel-xen<br />
</pre></code><br />
= Modify Xen guest config file in the dom0 =<br />
<br />
Now that the VM has been prepped for booting with pvgrub we need to update its configuration file to load the pvgrub kernel instead of a linux kernel.<br />
<br />
Note: be certain to remove the old “root=” line, this seems to confuse pvgrub. Also, make certain that the “extra=” line points to the location of your grub config file inside the guest. My example does not use partitions, if you do use partitions in your guests you’ll need so use something like (hd0,0), etc.<br />
<br />
<code><pre><br />
name = 'superchunk'<br />
<br />
vcpus =2;<br />
<br />
memory = 512;<br />
maxmem = 4096;<br />
<br />
#pvgrub here<br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0)/boot/grub/grub.conf"<br />
#end pvgrub<br />
<br />
disk = [ 'phy:/dev/vg0/vm_superchunk-root,xvda1,w', \<br />
'phy:/dev/vg0/vm_superchunk-swap,xvda2,w' ];<br />
<br />
vif = [ 'bridge=eth1, vifname=superchunk, mac=B0:00:00:00:B1:35' ];<br />
</pre></code><br />
= Shutdown and then create the domain =<br />
<br />
My Xen guest is named superchunk. You should be familiar with shutdown and create at this point. Here’s how, just in case…<br />
<code><pre><br />
xm shutdown superchunk<br />
#(wait until it has shut down)<br />
xm create -c /path/to/superchunk-config<br />
</pre></code><br />
At this point you should see some kernel output and then either a grub menu or the grub command line. If you get the command line, no worries. This usually means that it couldn’t find a grub configuration file. Make sure that the “extra=” line of the Xen guest domU configuration file references the right location and that you have pointed grub at the correct disk, i.e. (hd0) vs. (hd0,0), etc…<br />
<br />
Good luck! And feel free to drop me a line at soundsoldier@backdrift.org, I always appreciate feedback and do my best to help. <br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category::Beginners]]</div>7heohttps://wiki.xenproject.org/index.php?title=PvGrub&diff=7461PvGrub2013-04-09T13:30:36Z<p>7heo: </p>
<hr />
<div><!-- MoinMoin name: PvGrub --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: PvGrub --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Sat May 22 16:18:40 2010 (1274545120000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
PV-GRUB is an alternative to [[PyGrub]] to boot domU images safely: unlike pygrub it runs the regular grub inside the created domain itself and uses regular domU facilities to read the disk / fetch files from network etc.; it eventually loads the PV kernel and chain-boots it. There is a [[PVGrub_HowTo|HowTo]] on it in this wiki.<br />
<br />
= Configuration =<br />
* Boot domU from local disk:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(hd0,0)/grub/menu.lst"<br />
</pre><br />
<br />
* Boot domU from network:<br />
<br />
<pre><br />
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"<br />
extra = "(nd)/grub/menu.lst"<br />
</pre><br />
<br />
You should setup the DHCP server and TFTP server correctly. Create ${tftproot}/grub/menu.lst; copy necessary files (vmlinuz, initrd, etc.).<br />
<br />
= Reference =<br />
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto<br />
* [http://www.gnu.org/software/grub/manual/grub.html GNU GRUB Manual].<br />
* [http://os-drive.com/files/docbook/xen-pxeboot.html Xen PXE Boot Howto].<br />
<br />
[[Category:HowTo]]<br />
[[Category:Example]]<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
<br />
{{Languages|PvGrub}}</div>7heohttps://wiki.xenproject.org/index.php?title=XL&diff=7442XL2013-04-08T00:06:59Z<p>7heo: /* xl Upgrade Checklist */</p>
<hr />
<div>= Introduction =<br />
<br />
''xl'' was introduced in the Xen 4.1 release, however ''xend'' remained the default. As of Xen 4.2 however ''xend'' is deprecated (and will be removed in subsequent XEN versions) and ''xl'' should now be used by default.<br />
<br />
''xl'' is based on the xenlight library (''libxl''), a library designed to provide a common "bottom third" for any Xen toolstack.<br />
<br />
= Features =<br />
<br />
* PV and HVM guests.<br />
* Basic guest lifecycle operations: create, shutdown, reboot, pause, unpause, list, rename etc.<br />
* Guest device support, including hotplug and unplug:<br />
** Network devices (both para-virtualised and emulated)<br />
** Block devices (both para-virtualised and emulated)<br />
** Virtual framebuffer, keyboard and mouse both para-virtualised and emulated)<br />
*** Including SDL, VNC and SPICE output<br />
** PV console devices<br />
* Live migration and save/restore of guests,<br />
* Passthrough of PCI devices to guests.<br />
* VCPU pinning<br />
* CPU pools, including cpupool-per-NUMA node.<br />
* Control of CPU scheduler parameters<br />
* TMEM<br />
* XSM/Flash policy control.<br />
* Control of CPUID features exposed to guests.<br />
* Support for both the traditional Xen for of ''qemu'' (''qemu-xen-traditional'') and upstream qemu versions (''qemu-xen'')<br />
<br />
See also [[XL vs Xend Feature Comparison]]<br />
<br />
= Upgrading from xend =<br />
<br />
The ''xl'' toolstack is intended to remain backwards compatible with existing ''xm'' domain configuration files. It is therefore expected that any existing configurations should work with ''xl'' (although note the exceptions in ''Anti-Features'' below):<br />
<br />
Unlike ''xend'' the ''xl'' toolstack will not perform any host networking configuration for you. The ''xend'' code to reconfigure on startup is extremely fragile, prone to bugs when either distro or Xen are upgraded and rather difficult to debug. Instead ''xl'' takes the approach of deferring such network configuration to the distribution configuration tools which are usually well understood and documented. Therefore upon upgrading to ''xl'' it is necessary to configure your host networking stack appropriately. Please see [[HostConfiguration/Networking]] for more details on how to do this.<br />
<br />
You can find a feature by feature comparison of XL and Xen in [[XL vs Xend Feature Comparison]].<br />
<br />
Please report any other configuration file incompatibilities to the Xen developers on the [mailto:xen-devel@lists.xensource.com xen-devel mailing list].<br />
<br />
=== xl Upgrade Checklist ===<br />
<br />
* Configure your host networking using the configuration tools provided by your distribution. (See: [[HostConfiguration/Networking]])<br />
* Remove any python code from domU configuration files.<br />
* Disable xend startup script (it might also be needed to enable xl in the xen config (i.e. for debian in <code>/etc/default/xen</code>), and then to reboot).<br />
* Use ''xl'' command instead of ''xm''<br />
<br />
= Anti-Features =<br />
<br />
The following are explicitly not supported by ''xl'':<br />
<br />
* Managed Domains (a la ''xm vm-create''). Suitable alternatives: xapi, which is available as part of [[XCP]] or via [[Project Kronos]] or [http://libvirt.org libvirt] or some very simple scripting (e.g. the ''xendomains'' initscript). Also see [[Choice of Toolstacks]]<br />
* Python code in configuration files. See: [[PythonInXlConfig]]<br />
<br />
= Documentation =<br />
<br />
== Xen 4.2 ==<br />
<br />
{{Info|This section contains link to Xen manual pages that are generated from the Xen codebase. They reflect the state of '''xen-4.2-testing.hg'''.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document related to '''xl''' and '''xl.cfg'''<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xl.1.html xl(1)]<br />
| Xen management tool, based on LibXenlight<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xl.cfg.5.html xl.cfg(5)]<br />
| XL Domain Configuration File Syntax<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xl-disk-configuration.txt xl.cfg(5), '''disk''' configuration]<br />
| This document specifies the xl config file format disk configuration option. <br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xl-network-configuration.html xl.cfg(5), '''network''' configuration]<br />
| This document specifies the xl config file format vif configuration option. <br />
|- <br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/tscmode.txt xl.cfg(5), '''tsc_mode''' configuration]<br />
| In Xen 4 a new config option called tsc_mode may be specified for each domain. This document is targeted for Xen users and administrators that may need to select a non-default tsc_mode.<br />
|}<br />
<br />
== Xen unstable ==<br />
<br />
{{Info|This section contains link to Xen manual pages that are generated from the Xen codebase. They reflect the state of '''xen-unstable.hg'''.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document related to '''xl''' and '''xl.cfg'''<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xl.1.html xl(1)]<br />
| Xen management tool, based on LibXenlight<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html xl.cfg(5)]<br />
| XL Domain Configuration File Syntax<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt xl.cfg(5), '''disk''' configuration]<br />
| This document specifies the xl config file format disk configuration option. <br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html xl.cfg(5), '''network''' configuration]<br />
| This document specifies the xl config file format vif configuration option. <br />
|- <br />
| [http://xenbits.xen.org/docs/unstable/misc/tscmode.txt xl.cfg(5), '''tsc_mode''' configuration]<br />
| In Xen 4 a new config option called tsc_mode may be specified for each domain. This document is targeted for Xen users and administrators that may need to select a non-default tsc_mode.<br />
|}<br />
<br />
== Also See ==<br />
* [[XL vs Xend Feature Comparison]]<br />
<br />
[[Category:Beginners]]<br />
[[Category:Users]]<br />
[[Category:Developers]]<br />
[[Category:Compatibility]]</div>7heo