Changes between Initial Version and Version 1 of VirtualisationTools

Timestamp:

Aug 3, 2006, 3:22:26 PM (19 years ago)

Author:

andree

Comment:

Copy from BerliOS

VirtualisationTools

@@ +1 @@
+Use of virtualisation tools with Mondo Rescue can be quite helpful for development, testing and debugging. It can also help to give an administrator slightly more peace of mind in situations where real restore runs are not possible.
+
+The following describes the use of virtualisation tools available today in conjunction with Mondo Rescue. Note that the emphasis here is on doing restores in a virtual machine (VM). You are free to run mondoarchive inside the VM or guest.
+
+== QEMU ==
+
+QEMU is a CPU emulator for a number of different architectures both for the host and the guest (VM). Performancewise, QEMU lies probably somewhere between Bochs and VMware.
+
+=== Getting QEMU ===
+
+Being GPL'd software (as opposed to VMware), QEMU should come with your distribution, for Debian for instance their is a qemu package that work just fine (for me in sid).
+
+However, if QEMU is not included in your distribution or you want a newer version, you can get it from here: http://www.qemu.org/. I have not compiled it myself - so if you have feel free to add the missing details!
+
+Just insure that you're using gcc v3.x for your compilation of qemu/kqemu as gcc v4.x isn't supported yet. It may get tricky when you want kqemu (non-GPL) to load with your kernel as you'll need to have again the same compiler version which probably means for uptodate distros a kernel recompilation with gcc v3.x
+
+=== Setting Things Up ===
+
+QEMU comes with quite extensive information which includes a detailed manpage.
+
+Getting going really only requires the following two things though:
+
+Create a disk image using qemu_img:
+
+  qemu-img create hda.img 8G
+
+This will create a sparse 8 GB raw disk image. This is not a partition nor a filesystem, this is a disk. Sparse means that it will initially only use very little space in the host filesystem and keep growing as required up to 8 GB. As a side note, sparse also means that you can create a disk image file the size of your hard disk and have Mondo Rescue running a restore of your physical hard disk onto the hard disk image that QEMU uses as long as you have somewhat more than 50% of your physical disk free. This can be useful to avoid mondorestore coming up with errors saying there is not enough space inside QEMU.
+
+The second prerequisite is to have a mondorescue image or CD ready. You can just use mondorescue.iso that mondoarchive has created (under /root/images/mindi as default).
+
+=== Running QEMU ===
+
+Run QEMU, e.g. like this using the disk image we created beforehand and mondorescue.iso from our last mondoarchive run:
+
+  qemu -cdrom /root/images/mindi/mondorescue.iso -m 256 -boot d -hda hda.img
+
+That's it. If all goes well you get a new window with the familar Mondo Rescue boot screen.
+
+Some remarks:
+ * '-m 256' gives 256M of physical RAM to the qemu instance
+ * '-hda hda.img' could be written as just 'hda.img'. However, I include the switch for clarity sake. As a side note this means that only IDE 
+   disks are suppored by qemu, no SCSI.
+ * '-boot d' makes it so that qemu boots off the CDROM. Once a restore is finished and you want to check the result, i.e. verify that the 
+   restored system is bootbale and working, use '-boot c'.
+ * If the task is to boot off a real optical disk, use 'cdrom /dev/hdc' or whatever the correct device for the optical drive is.
+
+== Advanced Topics ==
+
+=== Networking ===
+
+==== Hardware ====
+
+QEMU emulates a PCI NE2000 NIC. This means you need support for this on your Mondo Rescue restore media. The only way I have gotten this to work is by appending 8390 and ne2k-pci to the NET_MODS variable in mindi (< 2.0.8) which may then look like this:
+
+  NET_MODS="sunrpc nfs nfs_acl lockd loop mii e100 bcm5700 e1000 eepro100 tg3 pcnet32 vmxnet 8390 ne2k-pci"
+
+==== Configuration ====
+
+QEMU does support networking in various ways. The simplest is the 'user networking' which means that no setup (and no command line switches) are required.
+
+QEMU has a DHCP server built in at address 10.0.2.2 which always issues IP address 10.0.2.15. Theoretically adding:
+
+  ipconf=dhcp
+
+should make it so that networking is started uding busybox' udhcpc. Unfortunately, I have not had any success with this yet. However, adding the following kernel parameter does the trick for me and yields a working network connection:
+
+  ipconf=10.0.2.15:255.255.255.0:10.0.2.255:10.0.2.2
+
+So, a complete kernel line at the prompt could read:
+
+  boot: nuke ipconf=10.0.2.15:255.255.255.0:10.0.2.255:10.0.2.2
+
+==== Using QEMU for mondorescue PXE mode ====
+
+I've found only one mode which works in a useful way for our tests:
+
+ * Create a disk image using qemu_img:
+
+  qemu-img create pxe.qemu 3G
+
+ * Let’s go to ROM-o-Matic to generate a  bootable image that support net boot for the emulated NIC ''(thanks to    
+   [http://tomas.andago.com/cgi-bin/trac.cgi/wiki/QEMUPXE])''
+   * Select last version (at 20060528 is 5.4.2)
+   * Chose NIC/ROM type. Qemu emulates Realtek 8029 - Choose ns8390:rtl8029 -- [0x10ec,0x8029]
+   * Select ISO bootable image for without legacy floppy emulation.
+   * Go under configuration page and add the following fields:
+     * Check USE_STATIC_BOOT_INFO
+     * STATIC_CLIENT_IP: 10.0.2.15
+     * STATIC_SUBNET_MASK: 255.255.255.0
+     * STATIC_SERVER_IP: 10.0.2.2
+     * STATIC_GATEWAY_IP: 10.0.2.2
+     * STATIC_BOOTFILE: /usr/local/tftpboot/pxelinux.bin
+   * Click on get ROM (a copy is available also at ftp://ftp.mondorescue.org/mondo/ftp/pxe/pxe-5.4.2.iso)
+
+ * Configure your pxelinux enironment as usual (refer to http://syslinux.zytor.com/pxe.php). For example, add to your pxelinux.cfg/default 
+   conf file the following lines:
+
+{{{
+label mondo
+        KERNEL kmondo
+        APPEND initrd=imondo.img load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=36864 rw root=/dev/ram expert_mode acpi=off apm=off devfs=nomount exec-shield=0 noresume selinux=0 barrier=off
+}}}
+
+ * Copy the correct kernel and initrd from your mondoarchive images:
+   * mount /mondo/mondo/images/victoria2-1.iso  /mnt/cdrom -o loop
+   * cp /mnt/cdrom/vmlinuz /usr/local/tftpboot/kmondo
+   * cp /mnt/cdrom/initrd.img /usr/local/tftpboot/imondo.img
+
+ * Use that iso to lauch your qemu VM:
+
+  qemu -hda pxe.qemu -cdrom pxe-5.4.2.iso -boot d -tftp /usr/local/tftpboot
+
+ * enjoy !
+
+==== Remote NFS Server Configuration ====
+
+Even if all the above works, access to the required NFS share to do a restore may still be impossible because the remote NFS server will not allow access because the mount request comes from an illegal port. You may find something similar to the following in /var/log/syslog:
+
+  May 24 17:20:01 emden2 rpc.mountd: refused mount request from aurich3.ostfriesland for /srv/backups (/srv/backups): illegal port 32889
+
+This is because QEMU does port translation to avoid clashes with host networking activities. The fix is to add the 'insecure' option in the NFS server's exports file, e.g.:
+
+  [...]
+  /srv/backups aurich3(rw,root_squash,sync,insecure)
+  [...]
+
+As a side note, NFS requests (and all other network traffic from QEMU) will appear to come from the host's IP address because of QEMU's internal network address translation (NAT).
+
+=== Issues ===
+
+mondorestore hangs when extracting configuration files from all.tar.gz from the loopback-mounted ISO image located on NFS server. A workaround is to boot in expert mode, to manually mount the first ISO image, e.g.:
+
+  mount /tmp/isodir/aurich3/aurich3_nfs_nofiles-1.iso -t iso9660 -o loop,ro /mnt/cdrom
+
+and to then copy all.tar.gz to /:
+
+  cp /mnt/cdrom/images/all.tar.gz .
+
+This will take a surprisingly long time. But after it has finished (the copy can be deleted) and /mnt/cdrom unmounted, 'mondorestore --nuke' should start ok.
+
+It looks like this may be somewhat fixed in 0.8.1 at least on Debian systems. For 0.8.1, the restore starts but then stalls after a number of files have been unpacked and then continues again after a few minutes and so on.
+
+Doing a restore from an ISO image works fine, though (minus the disk not found issue discussed in more detail under VMware Issues below).
+
+== VMware Server==
+
+The following was done on a Debian Sid system. It should work with slight modifications on any Linux system.
+
+=== Getting VMware Server ===
+
+VMware Server can be downloaded here: http://www.vmware.com/download/server/ :
+
+ * VMware-server-e.x.p-23869.tar.gz
+ * VMware-server-linux-client-e.x.p-23869.zip
+
+'''Note:''' At the time of this writing (24 May 06), this is still in beta and has an expiry date not too much in the future. This is supposed to change once the final version is out which will be unlimited.
+
+'''Note:''' There are other packages like VMware-mui-e.x.p-23869.tar.gz which are not required for a server/console only scenario.
+
+'''Note:''' Another possibility is to use VMWare VMPlayer.
+
+In addtion to the actual software, it is highly recommended to also get the following manuals from http://www.vmware.com/support/pubs/ :
+
+ * VMware Server Beta 3 Administration Guide
+ * VMware Server Beta 3 Virtual Machine Guide
+
+=== Setting Up VMware Server ===
+
+Call me a paranoid bastard, but I don't like running reasonably complex Perl scripts that scatter files all over my beloved Debian system. (The uninstall routine is said to work well, but I haven't used it.) So, before the actual installtion, we'll set up a chroot environment. You can skip this step if you are more trsuting than I am and directly proceed to installation.
+
+==== Setting Up The Chroot ====
+
+'''Note:''' debootstrap ''is'' Debian-specific. I am sure though that other distributions will have simialr tools for bootstrapping a system.
+
+The chroot will potentially be quite large in size depending on the number and sizes of the virtual machines. This needs to be taken into account when choosing the location of the chroot directory.
+
+Settings things up is then quite straight-forward:
+
+ * use debootstrap to create changeroot, e.g. (using local apt-proxy cache):
+      debootstrap sid ./sid-vmware-chroot http://emden2:9999/debian
+ * create normal user in chroot, e.g.:
+      chroot ./sid-vmware-chroot adduser andree
+ * mount things (needs to be repeated after every reboot, or see script below):
+      mount --bind /tmp ./sid-vmware-chroot/tmp
+      mount --bind /dev ./sid-vmware-chroot/dev
+'''Note:''' This will create some files in /dev, somewhat undermining the original purpose. However, without this, it does not work - there is a pipe error.
+      chroot ./sid-vmware-chroot mount -t proc proc /proc
+      chroot ./sid-vmware-chroot mount -t sysfs sys /sys
+ * in the chroot, install the following packages:
+   * psmisc
+   * libdb3
+   * gcc
+   * make
+   * linux-headers-`uname -r`
+   * xbase-clients
+   i.e.:
+      chroot ./sid-vmware-chroot apt-get install psmisc libdb3 gcc make linux-headers-`uname -r` xbase-clients
+
+'''Note:''' xbase-clients is definitely more than is strictly required. However, it comes with some potentially helpful tools.
+'''Note:''' linux-headers-`uname -r` is the headers for the running kernel. See below for implications.
+
+ * allow anyone access to X (needs to be repeated after every reboot):
+      xhost +
+
+ * use the following script to set the environment and to launch the console:
+  {{{
+  #!/bin/bash
+  #
+  # /usr/local/bin/chvmware - Start VMware in a chroot and bring up Console
+  #
+  # Changelog:
+  # 21May06AL: - initial version
+  # 22May06AL: - umount everything in chroot upfront
+  #            - umount /proc explicitly because -a does do it
+  #            - also mount /sys in addition to /proc in chroot
+  #            - use grep -c to count (and compare to 1 in mount checks)
+  #
+   
+  # simple parameter check
+  if [ $# != 2 ] ; then
+    echo "Usage: $0 <chroot dir> <user in chroot>"
+    exit 1
+  fi
+      
+  # parameters
+  CHROOT_DIR=$1
+  CHROOT_USER=$2
+      
+  # allow X to be accessed by anyone
+  xhost +
+      
+  # umount everything in chroot
+  sudo chroot $CHROOT_DIR umount -a
+  sudo chroot $CHROOT_DIR umount /proc
+      
+  # bind mount /tmp and /dev into chroot
+  if [ `mount | grep -c "$CHROOT_DIR/tmp"` <> 1 ]; then
+    sudo mount --bind /tmp $CHROOT_DIR/tmp
+  fi   
+  if [ `mount | grep -c "$CHROOT_DIR/dev"` <> 1 ]; then
+    sudo mount --bind /dev $CHROOT_DIR/dev
+  fi
+      
+  # mount /proc and /sys in chroot
+  if [ ! -a "$CHROOT_DIR/proc/cpuinfo" ]; then
+    sudo chroot $CHROOT_DIR mount -t proc proc /proc
+  fi
+  if [ ! -a "$CHROOT_DIR/sys/kernel" ]; then
+    sudo chroot $CHROOT_DIR mount -t sysfs sys /sys
+  fi
+
+  # start vmware if not running already
+  if [ -z `ps -C vmnet-bridge -o pid=` ]; then
+    echo would start vmware server
+    sudo chroot $CHROOT_DIR invoke-rc.d vmware start
+  fi
+
+  # start vmware console if not running already
+  if [ -z `ps -C vmware -o pid=` ]; then
+    echo would start vmware console
+    sudo chroot $CHROOT_DIR su $CHROOT_USER -c vmware
+  fi
+
+  exit 0
+  }}}
+
+'''Note:''' The largest remaining issue with the chroot is that the virtual machines are not properly stopped when the system goes down. This could be amended by means of an init.d script.
+
+==== Installing VMware Server ====
+ * unpack the server package:
+      tar xvzf VMware-server-e.x.p-23869.tar.gz
+ * change into the server directory and start the installation:
+      cd vmware-server-distrib
+      ./vmware-install.pl_
+'''Note:''' Leave everything at their default values but only choose first networking option, i.e. no NAT and no host only.
+'''Note:''' Ignore error regarding vmware-cmd.
+'''Note:''' This should automatically find the kernel headers. If the kernel changes the instllation process will have to run with the new 
+            header files.
+ * unpack the server console package:
+      tar xvzf VMware-server-console-e.x.p-23869.tar.gz (contained in VMware-server-linux-client-e.x.p-23869.zip)
+ * change into the server console directory and start the installation:
+       cd vmware-server-console-distrib
+       ./vmware-install.pl
+
+
+==== Running VMserver ====
+
+After installation, VMware should be running. If you have installed into a chroot the following should start VMware Console:
+  chroot ./sid-vmware-chroot/ su andree -c vmware
+
+If you have chosen a normal install, there may be an new icon in your menu. Alternatively, the following command should get you there:
+  vmware
+
+Lean back and enjoy or rather create your first virtual machine. Many things said about disk images and booting off ISOs for QEMU above apply here as well.
+
+==== Issues ====
+
+Restore works fine, after reboot GRUB starts up ok, the system starts booting but then can't find the harddisk. This happens both for Linux and Windows.
+
+The underlying reason appears to be the different IDE controller inside VMware as opposed to on the real machine. The restored systems are not prepared to deal with the new IDE controller inside the VM. Funnily enough, trying with kernel 2.4.27 does indeed work, but 2.6.16 does not (both stock Debian). The fact that Windows can't cope is not too surprising. Linux not working is more of a worry.
+
+In regards to Linux or more specifically Debian Sid, the problem is caused by the chipset driver not being included in the initrd image that is built when the kernel is installed. This can be fixed as follows:
+
+After the restore is finished (but before rebooting), remount the newly restored system to, say, /mnt/target. Note that this may entice mounting multiple partitions on top of each other. Then, chroot into /mnt/target, mount /proc and /sys and run dpkg-reconfigure for all kernel images. An example for a full session may look like this:
+
+{{{
+mkdir /mnt/target
+mount /dev/hda3 /mnt/target
+mount /dev/hda5 /mnt/target/tmp
+mount /dev/hda6 /mnt/target/var
+mount /dev/hda7 /mnt/target/usr
+mount /dev/hda8 /mnt/target/usr/local
+mount /dev/hda9 /mnt/target/home
+chroot /mnt/target
+mount -t proc proc /proc
+mount -t sysfs sys sys
+dpkg-reconfigure linux-image-2.6.16-1-k7
+exit
+umount -a
+reboot
+}}}
+
+'''Note:''' The idea of running dpkg-reconfigure on the kernel image package to rebuild the initrd image is not mine. Rather, it was suggested by Guillaume Pernot here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325877. Thanks, Guillaume!
+
+
+==== Appendix A: Sarge Differences ====
+
+ * Call debootstrap like this (using local apt-proxy cache):
+      debootstrap sarge ./sarge-vmware-chroot http://gateway:9999/debian
+ * Replace 'sid' with 'sarge' in all commands above
+ * Manually create file /etc/apt/sources.list in sarge chroot, e.g.:
+      deb http://192.168.1.1:9999/debian sarge main
+      deb http://192.168.1.1:9999/security sarge/updates main
+ * In Sarge, packages psmisc and libdb3 are already installed by debootstrap.
+ * Kernel headers package on Sarge is: kernel-headers-`uname -r`
+ * Install package module-init-tools for handling 2.6 kernels.