• In the "Monitor" section, add:

       HorizSync 28-51
       VertRefresh 43-60 

• Keep the "cirrus" driver

• In the "Depth 16" subsection of the "Screen" section, add:

       Modes "1024x768" 

local% ssh -X remote
remote%  qemu $options 
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  25 (X_SendEvent)
  Resource id in failed request:  0x40
  Serial number of failed request:  12
  Current serial number in output stream:  17 

remote% exit
local% ssh -Y remote
remote%  qemu $options 

Now if qemu from a remote machine was actually usable that would be nice - turns out the scroll speed is unacceptably slow, though. :(

Update: I was using qemu 0.8.0 on these machines, and after upgrading to 0.9.0, this version also offers running Qemu with a VNC server that one can then connect to. I still have to try that one from at home (working around a few firewalls :-/), but with some tricky SSH port forwardings that may be possible - and can't possibly be slower than just Qemu via remote X. Thanks to sec for the hint!

[Tags: qemu]

In related news, Manuel has updated the packages for the latest Xen release (3.0.3) and a new one to support HVM (which needs X, in order to emulate a VGA console via Qemu, see above). With that package, it was possible to boot systems that were not specifically prepared for use with Xen, e.g. NetBSD/i386, Linux and Windows XP! See Manuel's second posting and the followups.

[Tags: qemu, xen]

I did setup a 200MB harddisk image with NetBSD (could be anything). Instead of copying this huge file onto students' tiny (50MB quota) accounts, I used the "copy on write" feature of Qemu instead. Basically, the following script was given to students to run:

     $ cat ~hubertf/tmp/qemu/qemu.sh
     #!/bin/sh
     QEMU_HOME=/home/feyrer/tmp/qemu
     roimg=${QEMU_HOME}/harddisk.netbsd
     rwimg=harddisk.qemu
     
     if [ ! -f $rwimg ]; then
             qemu-img create -b $roimg -f qcow $rwimg
     fi
     
     qemu \
             -hda $rwimg \
             -cdrom ${QEMU_HOME}/i386pkg-3.0.iso \
             -boot c 

There are several interesting aspects of using Qemu this way: 1) it saves disk space for students, by using copy-on-write images. 2) Qemu doesn't need any kernel modules or special privileges to run. Whatever students do, they can not possibly violate host system security. 3) thanks to Qemu's built in network stack (and application level gateway, DHCP server, router, DNS server etc.), a lot of networking can be done from within Qemu. 4) Easy recovery as described above.

In short: Qemu rocks once more!

[Tags: qemu]

Setup and configuration was dead easy, and NetBSD comes with some excellent infrastructure to setup a machine that starts up multiple domUs automatically, by simply adding the needed config files into /usr/pkg/etc/xen.

The qemu disk image is 1GB in size so I'll not make this available (but can upload it on request, if someone wants?), but for kicks here are dmesg outputs of the host running qemu, the Xen dom0 running inside qemu and a Xen domU domain.

Harddisk usage of the 1GB disk is, in dom0: two 180MB disk images for the domU filesystems, mounted via vnd(4). About 100MB of additional packages are installed to manage Xen plus some other things pulled in to support that (Python, Perl and lots of modules), 100MB for X, some 200MB for a full installation of NetBSD 3.0/i386 (used on the Xen kernel) which includes development and text processing environment, documentation and manpages. The rest of the disk is dedicated to swap.

The system is setup to use grub as bootloader, which offers booting either a 'regular' NetBSD/i386 kernel (i.e. no Xen), or the Xen hypervison, which then boots a NetBSD/Xen kernel, that uses the NetBSD/i386 userland to boot.

After the system has booted to multiuser mode, started the two domUs, and after logging in as root, the domU consoles can be accessed by telnetting to localhost port 9601 and 9602, respectively. Networking for the domUs is setup in the domU config files: all domUs, the dom0 plus the physical ethernet interface are all plugged into a (virtual) switch (implemented via bridge(4)), which is then bridged to the "normal" ethernet - Voila, network for all domains!

FWIW, here's what a Xen domU config file looks:

$ cat /usr/pkg/etc/xen/hf1
kernel="/netbsd-XENU"
memory=32
name="hf1"
nics=1

vif = [ 'mac=52:54:00:12:34:57, bridge=bridge0' ]

disk = [ 'file:/harddisk.xen-hf1,wd0d,w' ]
root="/dev/wd0d" 

Installation of a Xen domU with NetBSD works by creating a harddisk image, and then using the INSTALL_XENU kernel, which boots right into an installer that can then be used to install NetBSD on the disk(image). Installation sets can be fetched using the local network e.g. via FTP from dom0. Of course after setting up one domU harddisk image, setting up the other one is a mere "cp img1 img2", with some small changes for hostname and SSH keys etc.

In summary, I'm very impressed by the "roundness" of the Xen integration into NetBSD - no hacking, just add config files, disk images, and off you go.

Mmm, NetBSD!

[Tags: dmesg, qemu, xen]

Anyone got success with sparc SMP, or booting NetBSD/sparc in general, or NetBSD/macppc or any of the AFM or MIPS platforms? Please let me know if so! :)

[Tags: qemu]

 #define IN_T int8_t
 
 ...
 
 #define ET glue (ENDIAN_CONVERSION, glue (_, IN_T))
 
 ...
 
 static void glue (glue (conv_, ET), _to_mono)
     (st_sample_t *dst, const void *src, int samples, volume_t *vol)
 { ... }
 
 t_sample *mixeng_conv[2][2][2][2] = {
     { 
         {
             {
 		conv_natural_uint8_t_to_mono,
 		conv_natural_uint16_t_to_mono
 	    }
 	    ...  

As it turns out, the NetBSD 2.x system I did this on actually has uint8_t (and others) as a #define to the corresponding types with __, which then leads to the above effect. Of course the right way is not to use #define but typedef here, but upgrading to NetBSD 3.0 (which does the right thing) is not an option right now).

So I tried to come up with some equally evil cpp(1) magic to expand the symbol in the second place, replacing:

 	conv_natural_uint8_t_to_mono,
 	conv_natural_uint16_t_to_mono 

 	NBglue(conv_natural_, uint8_t, _to_mono),
 	NBglue(conv_natural_, uint16_t, _to_mono) 

 	#define NBglue(x,y,z) x ## y ## z 

 	#define NBexpand(x) x
 	#define NBglue(x,y,z) x ## NBexpand(y) ## z 

 	#define _NBglue(x,y,z) x ## y ## z
 	#define NBglue(x,y,z) _NBglue(x,y,z) 

What lesson can be learned from this? 1) don't use #define where typedef is the right thing 2) don't blindly assume someone followed rule 1).

Oh, and someone please feel free to go back and clean up this whole code, apparently it was de-C++-ified at some time, according to some comment... :)

And finally, if someone's got some success with the kqemu or that other kernel-module whose name I forgot, please let me know! :)

[Tags: hubertf, qemu]