From Granizada

Virtualisation Demo In Server Track

Please don't post this URL outside the physical attendees, it isn't advertised and will vanish in less than two days.

IF YOU ARE NOT IN THE SERVER TRACK PLEASE WAIT UNTIL THE BREAKS TO COME AND SEE THIS. OR RICK WILL NOT BE HAPPY WITH ME.

Anotación
	This demo illustrates one OS running inside a VM running inside a VM. You can have any arbitrary OS, this just happens to be a subset of what I'm using to test OpenChange. The principle is that it is feasible to encapsulate numerous machines interacting with each other in a single VM image you can send to other developers.

Ok so yeah I know the OpenChange demo hasn't happened yet. Wait until the plenary session, with five quite major new things to announce, four of them ready for Intrepid if Ubuntu wants to accept them, I think you'll forgive me. It's been busy. I'll be summarising said announcements on a public page today for people outside UDS.

Anyway, following our discussions, here's one quick demo for this morning:

• The username and password for the Hardy desktop in the corner is written on a piece of paper. You shouldn't need them, but they are there if you do. With sudo. This machine has 8Gb of RAM and a more useful processor than a laptop.
• At the base level is a kvm session, with 4Gb of RAM. This is running the lessablons image, which is Hardy server x86_64.
• You will see a black-on-green xterm. This is a screen session onto the pty console for kvm.
• In the IceWM session you'll see:
  • a black xterm. This is the qemu commandlines for a 32-bit machine.
  • an xterm titled soren-eat-this. This is 32-bit, 750mb VM running Windows Server 2008 with Microsoft Exchange
  • a red xterm. This is a screen session onto the pty console for the soren-eat-this qemu.

My internal networking has gone to crap for the moment. Otherwise I'd have a Hardy running inside this as well. But at least this is something :-)

Note that even though I started both kvm and qemu with 'usbdevice tablet' and so the mouse makes smooth transitions between the three execution contexts, you need to think about the ctrl-alt focus capture. qemu wasn't designed for this scenario even though it works.

Things to try:

• Type "info kqemu" in the red screen
• at the RED screen type "sendkey ctrl-alt-delete" (get this right)
• Login to the Administrator account with password metro1+2=3
• In the red screen, type "savevm booted-and-running" (please use this name) to get an idea of how long it takes
• In the green screen, type "savevm booted-and-running" (please use this name) to get an idea of how long it takes

Conclusions

1. This is inefficient nested virtualisation. But it illustrates the point. I have had 4 VMs of various OSs talking to each other like this.
2. With some improvements, this is an extremely useful technique. The machines will run faster.
3. Most importantly, even if the machines never run faster, right now we can loadvm from a saved image of many machines talking, and start testing from a known point. I can send you a combined image.
4. We need a way of extracting the COW portion of qcow2 images against a known origin, so we can ship the differences around (eg by email.) This is what you can do with commercial virtualisation tools.
5. The technical changes required to do much better nested virtualisation are not large in extent, although there are very few developers capable of making these changes
6. The main point is for people to decide if this is interesting or not. Let me know.

Theory

This is all about having a single universal time domain for test and dev images. kvm/QEMU/Kqemu aren't great for this, but even now they help. Universal time domain is the key to better QA and quicker dev.