Xen and the Art of QCows

I've been working on a special project.. one that requires the building of multiple virtual machines on the fly. My VM of choice (as seen in previous entries) is Xen.

Part of my requirements is the ability to have a base image of a root drive, then have each of the dynamic VMs have their own dynamic image based on the original. One, if they wanted to, and had the space - could just copy the drive image multiple times. And this would work.

Fortunately, there is a better way. Copy-on-write disks are disks that write changes from a base image to a separate file. Thus, reducing the overall usage. This is what I want.

Xen wiki has multiple solutions to doing this, however, I wanted something simple, and supported at the xen level. This left me with qcow files.

In order to save some people some time. I wanted to describe how I went about getting the images to work -- pain for me, means less pain for you in the long run.

To make a long story short:

1. Created a image with dd (see previous posts)
2. Made my changes to the image
3. used "qemu-img convert -O qcow2 (base-img) (qcow-img)" to convert the image to a base qcow format
4. built the actual qcow files with "create-qcow (image-size) (container-qcow) (qcow-img)"

Some notes:

• When building your base image with dd - it CAN NOT be a spare file (meaning using the seek) it must be a full img
• img2qcow does not work! (or at least it didn't for me)

Some errors you might see

• Failed to write new L1 table  (Usually after: Converting image to big endian L1 table)
  
  • Your using qcow files, not qcow2 - probably because you used img2qcow or -O qcow with qemu-img
• QCOW Open failed
  • You may have used qcow-create, but referenced a raw image - not a qcow image.
• XENBUS: Waiting for devices to initialise
  • One of your devices didn't init in dom0 - look at /var/log/syslog to find the error in your ways

Getting OpenSUSE Kernel to work on Ubuntu

A little back ground: I like Xen - works (almost) great on my hardware. However there is a few bugs that still exist in the Ubuntu kernels, that newer kernels don't have. I've been told (via IRC) that SUSE (Open in my case) has some of the best support for Xen in it's kernels. So I'm documenting my Jurny in updating my Ubuntu Xen machine's Kernel to a newer OpenSuse Kernel:

First off, You need to download the new RPM from the website. The following link will give you a list of Xen Kernels for the [Almost] latest version of OpenSuse: http://software.opensuse.org/search?baseproject=openSUSE%3A11.0&p=1&q=Kernel-xen   Look for the one with the highest number - At this time it is: kernel-xen-2.6.25.20-13.1.i586.rpm

Download and extract the RPM into a temp directory: (Need to figure this one out - I use Midnight Commander, and I was able to enter the RPM, then enter the CPIO file, extracting tha data from there)

Once you have the extracted Directories (/boot, /etc, /lib, /usr) copy them to the root drive. There shouldn't be any duplicate files.

Ubuntu provides two scrtipts you need to run next;

1. Create a initrd.img file for the kernel by running: update-initramfs -k [kernel name] -c
   • Look for the installed System.map file to find the name, in this case it is 2.6.25.20-13-xen
2. Update your grub by running:  update-grub

[At this point, I did things in the wrong order so I Crashed, I'll update this after I test again.]

Update 1:
- I just rebooted the server after re-running the update-grub command. This time, I got a full boot, but Xend didn't seem work. I'll need to work on this issue next.

Marital Tiff between Sprint and Cogent?

There have been some reports that Sprint and Cogent are having a bit of a problem.

Seems they are in a tiff about the peering agreement. Sprint has since removed their peering from Cogent.

This basically means, traffic to/from sprint and cogent need to find a different way to route between them. This effects anyone down stream as well. Meaning, if you have a internet link from Sprint, and try to get to someone on Cogent's network - you may not be able too.

This would all hinge on whether or not they have peering agreements with others that allow them to route the other networks - which may not exist since they already had peering.

This is gonna cause some internet instability for some users.

http://isc.sans.org/diary.html?storyid=5264
http://tech.slashdot.org/tech/08/10/31/0439245.shtml

PR from Cogent is here: http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/10-30-2008/0004915721&EDATE=
I was not able to find PR from Sprint.

Internet Heath Report: http://www.internetpulse.net/Main.aspx?Period=RH1

(Sorry for the unlinkable links - seems something is messed up with my Beta Browsers - Teach me to run only beta browsers)

** UPDATE 11/3/08 11:00AM **

It seems Sprint was disconnecting Cogent from it's network back in early October. The finally cuts only happened on the 31st. This will get interesting to see what happens next.

Sprint's response to the disconnect: https://www.sprint.net/cogent.php

On a good note - it appears as tho the link was brought back up in the last 24 hours.

MS Security Alert - OCT 2008

** MS Security ALERT **

Ubuntu Encrypted Loopback Disk

So I have a need for a encrypted disk - as a loop back file. I wrote earlier on how to restore a partimage backup to loopback, so lets see if we can make this work.

1. We need to tell the kernal how to encrypt disks with a module

   • modprobe cryptoloop

2. Create the loop file (like before, but with urandom to help hide the disk, the count is MB*1000 so in this case 1M)

   • dd if=/dev/urandom of=myharddisk.img bs=1000 count=1000 

3. Create the loopback device (I'm going to use TwoFish)
   

   • losetup -e twofish /dev/loop0 ./myharddisk.img

4. At this point, you will be asked for a password - create your own
5. Create the file system of choice (ext3 for me)

   • mkfs.ext3 /dev/loop0  
     

6. Mount the new loop back point /dev/loop0

   • mount /dev/loop0 /mnt/my/mount/point

Enjoy!