Difference between revisions of "Xen"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
Line 5: Line 5:
 
== Xen Documentation sources ==
 
== Xen Documentation sources ==
  
 +
* [http://wiki.xensource.com/xenwiki/ Xen Wiki]
 
* [http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html Xen project documentation]
 
* [http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html Xen project documentation]
 
* [http://www.redhat.com/rhel/virtualization/ RHEL virtualization front page]
 
* [http://www.redhat.com/rhel/virtualization/ RHEL virtualization front page]

Revision as of 00:38, 17 January 2008

Xen

We currently run Xen on Pumpkin. Xen is a system to allow multiple "host" operating systems to run on the same hardware. The correct terminology is a "domain0" host system, which has direct control of the hardware via a "hypervisor" and domU guest systems which can be either Para-virtualized (faster, but requires a special kernel that is Xen aware) or Fully-Virtualized (slower, because it requires all the hardware to be emulated.)

Xen Documentation sources

Creating a new Virtual Host from a previously installed disk.

It seems one can do the following to create a clone of a physical system as a fully virtualized domU. This still needs to be tested better!

  • Stick the disk with the operating system on it in slot 23 or 24.
  • Create a new fully virtualized host:
    • In virtual machine manager, click create new.
    • Choose a name, as in: VHost23_sde
    • Choose for a fully virtualized host, para-virtualized is likely to get you into trouble (or will it?)
    • Choose to install from the image at /data1/. This is a RHEL5 image. Choose the operating system version.
    • Choose the disk: /dev/sde or /dev/sdf
    • Set ethernet to xenbr1
    • Set memory (probably 1024) and cpus (probably 2)
    • Save config (click finish)
  • You can now boot the virtual system. (It will do this automatically.) When prompted Do not install a new system (idiot!) instead type "linux rescue".
  • When the rescue boots, it will look for installed operating systems.
  • From the rescue console you can figure out what the hardware signature is. Now some files on the operating system need to be adapted to the new (temporary) hardware signature. You could also do this ahead of time by mounting the disks on pumpkin and modifying the files there.
Backup all files you modify to a *_Physical version, so you can undo this before sticking it back into the physical system. Keep track of your changes on the wiki!
Hard disk will be /dev/hda*   ==> Modify grub.conf (or use LABEL=ROOT and label your partition), with LVM systems you should be OK.
                              ++> A problem with labels is that they don't "stick". It seems that if you made the label while the
                              ++> disk was mounted on the host, it is not seen while mounted on the guest. You need to do these
                              ++> things from the guest operating system. This is also true for installing (re-installing) grub.

                              ==> Modify /etc/fstab (probably change /dev/sda* to /dev/hda*)
Ethernet               ==> Modify /etc/modules.conf or /etc/modprobe.conf and alias eth0 8139cp (REALTEK 8139cp driver) Needs test
                              ==> Same for eth1
  • Exit the console, or shutdown the machine. Now add another ethernet card to the config, hooking this up to xenbr0
  • Restart your virtual system. Make sure all VM disks are unmounted from pumpkin

If you need to fix things, or poke around, and want to boot from the iso image again, change the disk line in the /etc/xen configuration file to:

boot="d"
disk = [ 'phy:/dev/sdf,hda,w','file:/data1/rhel-5.1.-server-i386-dvd.iso,hdc:cdrom,r']   

Then run "xm create hvmconfig_file" to load your changes and boot the new config. It will boot from the cdrom image.

This seems to work! Remember to change boot="d" back to boot="c" to boot from your disk.


For the "FullVirt24_sdf" system I ran into an difficult problem: the initrd was no good. There was no way to "repair" this, since it needs a booted system to create a new initrd. I guess I could get an initrd from elsewhere and put that on the /boot with matching kernel. Instead I decided to reinstall RHEL4, calling this sytstem "Landau".

Xen Tools

I found that the "harddrive on a file" for a system is incredibly slow. Only use it in an emergency!

To open and manipulate such a file use the kpartx tool. Only do this if when the domU is shut down!

 >kpartx -l <filename>     #  Show the partitions on the file.
 >kpartx -av <filename>  #  create devices using loops corresponding to the partitions.
 add map loop2p1 : 0 208782 linear /dev/loop2 63
 add map loop2p2 : 0 20257965 linear /dev/loop2 208845
 # These loop2p1 etc can be found in /dev/mapper/loop2p1 etc.
 mount /dev/mapper/loop2p2   /mnt/tmp   # Mount the second partition on /mnt/tmp
 ..... do your work ....
 umount /mnt/tmp
 xpartk -d <filename>