Yesterday, I talked about QEMU and what it can do. As I've been working with it, there are a couple of reasons I want to run an OS under QEMU with Solaris 10 as my Host.
1) I need/want to run some Windows applications that I don't have under Solaris (say acrobat 7 or real player).
2) I want to test an OS out without having to frag my laptop again (as I've been doing since last year with Solaris 10 in beta, and now Solaris 10.1 [aka 11] in beta)

Getting started with QEMU

Assuming you can follow the download and patching of qemu-0.7.0 from yesterday, then running of

     ./configure --prefix=/tmp/qemu --with-oss=yes --oss-inc=/opt/oss/include; gmake install

the next thing you need to do is setup a working area. For the purposes of the demostration, I use /export/src/images as my top level directory where I keep the QEMU images. I also use /export/src/iso as the location for any CDROM image iso files I use to boot/install a guest OS under QEMU.

     $ mkdir -p /export/src/iso /export/src/images
     $ cd /export/src/images
     $ mkdir Knoppix_3.8
     $ cd Knoppix_3.8

The great thing about Knoppix is the ability to boot a complete OS on a PC without having to touch the hard disk, not to mention it's free and they have several yearly updates to the code base. These disks have become great recovery tools and have a lot of different uses. My favorite use of Knoppix is a test of how QEMU is running. Since it seems to take about 4 hours to install Solaris Express from a DVD image in a QEMU session, I'm really not interested in finding out it doesn't work after 4 hours. Plus, since it doesn't really require any disk space requirements at all, starting Knoppix under qemu is dead simple. Not everyone has Windows 98, 2000, XP, etc, and the time requirements to actually get comfortable with it are minimal compared to the amount of time it's taken me to get things like a 5 CD iso build of JD3 Linux/Build 32 installed, or Solaris Express on DVD. So I think is a pretty good example, plus I think any tech ought to be carrying a Knoppix disk, or something like it.

Getting Knoppix 3.8

Assuming you've gotten a Knoppix 3.8 iso image from your local bittorrent, and burned it to a CDROM, this is all you need. Blastwave has a version of bittorrent for Solaris, so getting a copy is just a matter of doing a "pkg-get -i bittorrent", assuming you loaded pkg-get from www.blastwave.org. (It seems that Knoppix V 3.7 was the last version available via FTP)

Booting Knoppix 3.8 from a CDROM under QEMU

So either you have an ISO image sitting in a directory like /export/src/iso/KNOPPIX_V3.8.1-2005-04-08-EN.iso or you actually burned the image onto media and it's in a CDROM drive in the Solaris system. If you are running vold (volume managment), we need make sure we can see the physical device.

$ eject -q cdrom       # to get the volume name of the knoppix disk
                       # it should be something like /vol/dev/dsk/c1t0d0/knoppix
                       # but we really need to give it the rdsk name so it can boot it.
#
#  To start Knoppix under QEMU if using a real CDROM under Solaris with vold enabled, try
#
$ /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio -pci -m 512 -k en-us
#
#  To start Knoppix under QEMU if using an ISO image file under Solaris, try
#
$ /tmp/qemu/bin/qemu -cdrom /export/src/iso/KNOPPIX_V3.8.1-2005-04-08-EN.iso -user-net -enable-audio -pci -m 512 -k en-us
#
#
# -user-net      : enables the slirp network stack that QEMU presents to the guest OS. This is default
#                  if you don't have tunnels (The tunnel code in QEMU for solaris is not quite there yet)
# -enable-audio  : have QEMU present a Soundblaster 16 to the virtual machine
# -pci           : have QEMU present a PCI bus.  The opposite is ISA, but at this point is only useful for
#                  things like DOS. Solaris Newboot as a guest chokes on "-isa"
# -m 512         : the ammount of physical memory to be given to QEMU for this guest OS.
#                  my system has 1536MB so giving it 512 is not too bad. This variable you
#                  will need to be careful with.
# -k en-us       : Sets up the keymapping for QEMU. Seems to be important if you're doing a savevm/loadvm,
#                  which I'll talk about later.
#

What you see immediately is a screen that looks like this. At this prompt type:

     boot knoppix screen=1152x864 dma # or screen=1024x768, something workable with your display window
                                         # 1152x900 works in JDS but for some reason doesn't work on Solaris. Go figure.

This takes about 15 minutes to boot on my PIII/1Ghz, and about 7 minutes to boot on my 2GHz Athlon XP. What this gives you is a working Knoppix instance running in QEMU under a Solaris host. Assuming you don't have any compile problems, and your Solaris host has a valid network/DNS mappings, your Knoppix guest OS should have an eth0 interface with an address of 10.0.2.15. Since QEMU provides a virtual DHCP server to the client (How else did it get that 10.0.2.15 address), and proxies DNS from a virtual host using 10.0.2.3 and having a defaultroute of 10.0.2.2, networking for the most part should just work. One big caveat - You cannot ping out of a guest OS to the host or any other address because SLIRP does not support ICMP. Telnet, FTP, SSH/SCP, X11, VNC and Samba all work without issue.

To verify, open a kconsole window (In your Knoppix QEMU Guest) , and run:

     $ ifconfig eth0

and see

     eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
               inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
               inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
               RX packets:634 errors:0 dropped:0 overruns:0 frame:0
               TX packets:571 errors:0 dropped:0 overruns:0 carrier:0
               collisions:0 txqueuelen:1000 
               RX bytes:267069 (260.8 KiB)  TX bytes:53495 (52.2 KiB)
               Interrupt:11 Base address:0xc100 

(YES, your networking will look *exactly* like that, because the "virtual machine" presented by QEMU to the guest OS looks the same.)

One thing that occurs when you click your mouse into the QEMU guest OS window, is that QEMU grabs it, and doesn't let go of it. If you feel like you've lost your mouse, hit CTRL_ALT and see if it releases your mouse so you can go outside the QEMU window.

Start firefox and surf the web (though if your Solaris host uses a web proxy, so should the Guest OS's brower). You can ssh to your Solaris host (make sure to use the real network address of the host, not 127.0.0.1). FTP also works, but I find that often you may have to use passive mode ("quote pasv") in the ftp client to pass data back and forth. I've found ssh/scp much easier to work with when dealing with a QEMU guest OS and the user-net stack.

Booting Knoppix Really Fast

QEMU has the ability to save the state of the local VM, and restore back to it from the command line. How we do this is by going into the QEMU monitor using [CTRL-ALT-2]. The monitor is a command line tool which provides a set of of tools and features, as displayed by this help menu

     QEMU 0.7.0 monitor - type 'help' for more information
     (qemu) help
     help|? [cmd] -- show the help
     commit  -- commit changes to the disk images (if -snapshot is used)
     info subcommand -- show various information about the system state
     q|quit -- quit the emulator
     eject [-f] device -- eject a removable media (use -f to force it)
     change device filename -- change a removable media
     screendump filename -- save screen into PPM image 'filename'
     log item1[,...] -- activate logging of the specified items to '/tmp/qemu.log'
     savevm filename -- save the whole virtual machine state to 'filename'
     loadvm filename -- restore the whole virtual machine state from 'filename'
     stop  -- stop emulation
     c|cont  -- resume emulation
     gdbserver [port] -- start gdbserver session (default port=1234)
     x /fmt addr -- virtual memory dump starting at 'addr'
     xp /fmt addr -- physical memory dump starting at 'addr'
     p|print /fmt expr -- print expression value (use $reg for CPU register access)
     i /fmt addr -- I/O port read
     sendkey keys -- send keys to the VM (e.g. 'sendkey ctrl-alt-f1')
     system_reset  -- reset the system

Assuming you started your session as I described, you can hot-key between the QEMU guest, the QEMU monitor, and the QEMU serial port. CTRL-ALT-1 from the MONITOR or QEMU serial port will take you to the Guest OS. CTRL-ALT-2 from the Guest OS or the QEMU serial port will take you to the MONITOR. CTRL-ALT-3 from the GUEST or the MONITOR will take you to the QEMU serial port.

Saving a running QEMU Guest OS session

Use CTRL-ALT-2 to go to the MONITOR and type

     savevm knoppix-save.vm

then

     quit

You will find a file created in the local directory (still in /export/src/images/Knoppix_3.8, right?) called knoppix-save.vm which contains the memory contents of the virtual machine. Since we're running off of a CDROM iso image, it doesn't matter about what's in the "file system". We're not using one yet. As you can see, the more you do with QEMU, the more command line parameters you need, which is why I wrote the script to do this. There are some java GUI's, but I'm a command line kind of guy, so I write my own stuff. Restart the Knoppix session using the command from above plus a new parameter -loadvm knoppix-save.vm and make sure that the amount of memory you originally specified at the time you saved this instance is the same that you start the -loadvm knoppix-save.vm: like:

     /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio \
                        -pci -m 512 -k en-us -boot d -loadvm knoppix-save.vm

This will have the Knoppix system back up in about 10 seconds. Once the system is back up, switch to the QEMU console with [CTRL-ALT-2], then switch back to the VM using [CTRL-ALT-1]. This appears to prevent the weirdness I'm seeing with a Konsole window and the keyboard interaction, where the keyboard doesn't seem to work correctly. But still, it's much faster than the 15 minutes it took to actually start the virtual machine from a dead stop.

This is all fine and good in testing. However, the savevm/loadvm feature is more likely to be used on Operating Systems that have a read/write disk, and not a read-only disk such as a CDROM or ISO image. This is where it gets tricky. In order to prevent corruption of the Hard disk image file containing the Operating System, if you use the savevm/loadvm feature, it is imperative that you not boot the disk image without the -loadvm and it's statefile. Otherwise, some pretty serious corruption could take place.