Virtual Iron (VI) is a commercial virtualisation product based on Xen
3.1 dom0 which boots unmodified bsd.rd i386 and installs in a domU. As
you can see from the dmesg below, it occasionally complains about
timeouts on re0, and the virtual console gets cluttered in the later
stages of the install. Other than that, login into sshd on the virtual
OpenBSD box works, although I have not done exhaustive tests regarding
stability nor performance.

So far, I had no success in booting bsd.mp, however. Even after
 set image bsd.mp
 boot -c
 disable apm
 enable acpi
 exit
bsd.mp stops after printing "nvram: invalid checksum".

When leaving the defaults (e.g. apm enabled and acpi disabled), bsd.mp
stops just after printing this, followed by
"apm0: APM system defaults failed: unknown error code? (83)"
"apm0: disconnected"

If someone is interested in having a closer look, then I will try to
make transcripts from the virtual console (or screenshots).

VI 4.0 was released last week. Even if it officially supports only a
handful of selected guest OS as of now, and there no VI Tools
available for OpenBSD (yet - source is available), I gave it a try on
virtualized Sun Fire X4600 M2 servers with iSCSI IP SAN arrays from
EqualLogic in a pre-prod lab. VI is an interesting alternative to ESX
from VMware, and it also competes with XenSource.

Regards,
Rolf


# dmesg
OpenBSD 4.2-current (GENERIC) #405: Thu Sep 13 16:06:09 MDT 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Dual-Core AMD Opteron(tm) Processor 8220 ("AuthenticAMD"
686-class, 1024KB L2 cache) 2.81 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16
real mem  = 536416256 (511MB)
avail mem = 510992384 (487MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @
0xfa3b0, SMBIOS rev. 2.4 @ 0xe901f (11 entries)
bios0: vendor Xen version "3.1-070908"
bios0: Xen HVM domU
apm0 at bios0: Power Management spec ...
[ message continues ]

Hi,
If it's based on Xen, you probably can change the type of network card in
the configuration file to avoid the network problem.
I have try each of them (pcnet, rtl8139(by default) and ne2kpci) on Xen dom0
and launch a iperf to test performance :
vif  = [ 'type=ioemu, bridge=xenbr1, model=pcnet' ] -> 54.1 Mbits/sec
vif  = [ 'type=ioemu, bridge=xenbr1, model=rtl8139' ] -> 182 Kbits/sec (with
many timeout from the card)
vif  = [ 'type=ioemu, bridge=xenbr1, model=ne2k_pci' ] -> 16.5 Mbits/sec



-- 
Julien Cabillot

[ message continues ]