Project Report - Adding PXE Boot Into Palacios
Total Page:16
File Type:pdf, Size:1020Kb
Project Report - Adding PXE Boot into Palacios Chen Jin Bharath Pattabiraman Patrick Foley EECS Department EECS Department EECS Department Northwestern University Northwestern University Northwestern University chen.jin@eecs. bharath@u. patrickfoley2011@u. northwestern.edu northwestern.edu northwestern.edu ABSTRACT PXE is a standard for booting an OS from the network. Most machines BIOSes support it. But, the BIOS used by Palacios guests did not. In our project, we tried various ways in which PXE network boot capability could be added to Palacios. We used a PXE-capable Etherboot ROM image from ROM-o-matic.net that has support for our emulated network card. We then used this small ISO image to build the guest and let it serve as a replacement PXE-boot ROM for the emulated network card. With passthrough I/O, the requests are handed over directly to the host, which are then sent to the DHCP and Boot servers to initiate the network boot process. The PXE capability will of vital importance in diskless nodes where the node is completely dependent on Figure 1: PXE system configuration the network for booting. 1. INTRODUCTION using PXE protocol and then boots the guest. PXE (Preboot eXecution Environment) allows us to boot Kitten/Palacios (and a test guest) remotely from a network server. Booting Palacios/Kitten over a network server is 2. SYSTEM already possible. In this research effort we have enabled So, as shown in Figure 1, in order to use PXE we need to Palacios to remote boot a guest OS using PXE. setup a PXE-server which can allow client systems to: PXE is defined on a foundation of Internet protocols, namely • TCP/IP, DHCP, and TFTP. In brief, the PXE protocol op- Request an IP address (via DHCP) erates as follows. The client initiates the protocol by broad- • Download a kernel (via TFTP) casting a DHCPDISCOVER containing an extension that identifies the request as coming from a client that imple- ments the PXE protocol. Assuming that a DHCP server 2.1 Server Configuration implementing this extended protocol is available, after sev- On the server end of the client-server interaction there must eral intermediate steps, the server sends the client a tempo- be available services that are responsible for providing redi- rary IP configuration and list of appropriate Boot Servers. rection of the client to an appropriate Boot Server. For our The client then discovers a Boot Server of the type selected purposes we used Knoppix (an operating system based on and receives the name of a bootloader file on the chosen Boot Debian) running on Qemu to behave as the DHCP server Server. The client uses TFTP to download the bootloader and the Boot (TFTP) server. Knoppix has DHCP server from the Boot Server. Finally, the client initiates execution and TFTP server pre-installed, so we just had to configure of the bootloader which boots the kernel. In our project the it in the following way. first request should be sent after Kitten and Palacios have booted up, so that Palacios gets the bootloader of the guest 2.1.1 DHCP Server Configuration subnet 172.21.0.0 netmask 255.255.0.0 f range 172.21.0.3 172.21.0.100; option broadcast−address 172.21.0.255; g group f next−server 172.21.0.2; host t e s t f f i x e d −address 172.21.0.50; qemu−image create −f qcow2 knoppix.img 4G hardware ethernet 52:54:00:12:34:57; filename "pxelinux.0"; g Now we launch a qemu command to start a virtual machine g with 128M memory, using the created hard drive image and booting from a CD-ROM image. Once the emulated ma- chine launched, we can start the regular installation process 2.1.2 TFTP Server Setup by first formating and partitioning the hard drive image and According to [3], when a client boots up it will check if then install knoppix on the hard drive image. there is a file corresponding to its own MAC address in the qemu −hda knoppix.img −cdrom knoppix. iso "/var/lib/tftpboot/pxelinux.cfg/" directory. However after −boot d −m 128 trying several options it will fall back to requesting a default su file. So, we simply changed to default file to contain the fdisk /dev/hda configuration we want. DEFAULT k i t t e n From the fdisk partition menu, create a primary Linux par- LABEL k i t t e n tition on partition 1 of 3600MB and a Linux Swap partition kernel bzImage on partition 2 of 400MB (remainder of the disk). Make par- append serial .baud=115200 console=serial tition 1 the active partition, but I'm not certain that because initrd=init t a s k of how QEMU boots a system on whether or not this make any difference. But that's how people do it with a normal 2.2 Client-Server Connection hard disk so let's do it that way here. Write out the changes To make the server and client Qemu's talk to each other we to the disk and then do a mkfs /dev/hda1. Once that is connected them together using vlans. The way this works complete, Halt the Knoppix image and restart it with the is that one qemu process connects to a socket in another above command line. Once you see the Knoppix prompt qemu process. When a frame appears on the vlan in the again like this type: first qemu process, it is forwarded to the corresponding vlan boot knoppix screen=1152x864 dma in the other qemu process and vice-versa. tohd=/dev/hda1 This way, the server and client Qemu's are connected using a socket interface connected to vlans. Thus, any frames and then feel the disk spin for a bit, with the screen looking transmitted by the client is received by the server, and vice somewhat like this. When it's all done, Knoppix will boot versa. normally. What this actually does is just copy over the di- rectory structure on the CDROM onto the Hard disk. Now, 3. IMPLEMENTATION when you boot from your cdrom, you can add fromhd=/dev/hda1 In this section, we will walk you through our implementation which will make it boot off the hard disk image. Given all process step by step from setting up a test bench for PXE efforts spent in this phase, this is probably worthwhile to booting testing and how we actually implemented it inside in create such a hard drive. The start line for qemu doesn't Palacios VMM. Actually, we spent quite an amount of time change from the previous run, but how we invoke Knoppix to understand what PXE booting is and how actually to is different. At the boot prompt, type: create the test environment for us eventually to work on the boot knoppix screen=1152x864 dma main part of this project. In the remainder of the section, fromhd=/dev/hda1 we will describe the test bench setup, how to execute our idea progressively and finally made it work. After using a HD install, knoppix boots considerably faster 3.1 Testbench setup than boot from iso image, however, it would take 10-15 Since PXE is a standard for network booting, it is critical minutes to populate all the devices. we looked at how we for use to set up the server-client system which allows us to could make QEMU boot a system much faster using the conduct the experiments. We started work from server side savevm/loadvm commands from the monitor. Once the which provides TFTP and DHCP services and the initial above system has booted, and we've got all the applications files for boot loaders. setup the way we want them, then type CTRL-ALT-2 to go into the QEMU monitor. Once inside the QEMU mon- 3.1.1 server itor, type "savevm knoppix-save.vm" and then "quit". The file knoppix-save.vm should be save. Note that not all file In order to avoid reconfiguring the system every time we use formats support this. raw does not, but qcow2 does. the Qemu, we decided to create a hard drive image which can save all the configuration changes we have made. We Restarting a QEMU savevm'd image initially tried to install ubuntu, however, the installation took so long. After trying several different linux kernels, we Once again, we add another parameter to the startup line picked knoppix that takes reasonable time to install, and for the qemu instance. To get the very quick restart of a provides both tftp and dhtp services. running image, we run: The following command allows users to create a qcow2 hard qemu drive image with size of 4G is −cdrom /vol/dev/rdsk/c1t0d0/knoppix Figure 2: Tap Device Diagram −m 512 Figure 3: VLAN Diagram −k en−us −boot d −hda knoppix.img −loadvm knoppix−save .vm and in about 10 seconds, my Knoppix instance is back where it was when I ran the savevm command from the QEMU monitor. After you restore an image like this, I found out that you should do a [CTRL-ALT-1] to reset the virtual machine's system state, which explains the weirdness I saw with the keyboard and restored image. I wish I had found this sooner. Waiting 10-15 minutes for something to bootup and enumer- ate all the devices is pretty hideous. Once the hard drive image is set up, the next problem we Figure 4: Socket Connection Diagram faced was to transfer the boot loader files to the server.