I have problems with Sun, just a different kind of problem and a different kind of Sun. And I don’t mean I have a problem with the company, Sun Microsystems but rather with some of their products.
The first problem is that, as an upstream they aren’t pleasing to work with. For instance, they changed without notice the file containing the tarball of StudioExpress, just to add some checksumming functionality to make sure the file was properly downloaded before starting. They had the decency of adding a -v2 note on the filename, but it still doesn’t help that they don’t show any changelog for that change, or announce it. I guess somebody resumed looking at security bugs for this to happen since the thing happened almost at the same time as their bug tracker started spamming me many times a day with a notice that some of the bugs I reported has changed details.
The second problem is less of today and more a continuation if a long saga that is actually quite boring. I’ve tried again to get OpenSolaris to work on VirtualBox, but with the new networking support (the vboxnetflt module), the network is tremendously slow, and both NFS and SSH over it as as slot as using them on a 56k modem connection. The main problem being that from time to time the ssh stream freezes entirely, making it quite infeasible to run builds with. Since Solaris, VirtualBox and networking has never been quite that good, and the thing hasn’t improved much now that VirtualBox is developed directly by Sun.
So I decided to use the recently resurrected Enterprise to install OpenSolaris on a real box; the idea was to use the dismissed working disks from Yamato to install not only OpenSolaris but also FreeBSD, NetBSD, DragonFly and other operating systems so I could make sure that the software I work on is actually portable. Unfortunately since I moved to pure SATA (for hard disks at least) a longish time ago, it seems like it’s not that easy: OpenSolaris failed to see any of my disks.
Okay so today I finally took the time to look up an EIDE disk and set it up, I start the OpenSolaris live CD and ask for install. And again it fails to find the hard disks; I would have thought it would be a problem with the motherboard, if it wasn’t that using SysRescueCD I get everything exactly as it should be. Which is more than I can say of my MacBook Pro, whose logic board seems to be bad, and can’t find its own hard drive any longer. I’m waiting to know how much money would it cost me to repair it and then I’ll take it to be repaired (unless it is way too much). This has been unlucky since I had to buy a new laptop for my mother just last week (the iBook I’ve bought six years ago has a bad hard drive now).
So I still don’t have a working setup where to try OpenSolaris stuff, this is quite not nice since I really would like to have my stuff portable to OpenSolaris as well as Linux. Oh well.
Use qemu then. Or you ignore it for principled reasons? FreeBSD, DragonFly, OpenSolaris work with -kernel-kqemu, OpenBSD and NetBSD require minor kqemu patching to enable user mode.
Well, I wanted to investigate using OpenSolaris for storage purposes (need more disk space than single Yamato can provide), but the thing went quite haywire.I’m using VirtualBox for Windows XP because the “additions” really make it much simpler to deal with, but other than that I have no use for any VirtualBox stuff on OpenSolaris.And indeed I started investigating qemu 0.10 with kqemu support (not yet kvm support), FreeBSD seem to be quite fast but I haven’t been able to connect the qemu virtual machines to the whole of the network (not with NAT). I’ll have to try harder.
If networking works with a single vm, check that all the guests use different MAC addresses (qemu always assigns 52:54:00:12:34:56).
I can’t seem to get a single vm to not pass through the NAT. I created the tap device qemu0, set up dhcpd on a /32 network for that, and started qemu (as root otherwise it doesn’t seem to be able to connect to the tap device, by the way) but it still provides me with a 10.0.0.0/8 address on the VM when I launch dhclient.
Configuring the tap interfaces and the bridge as persistent system interfaces is highly recommended, so this is just an example how to create an isolated virtual network:% sudo tunctl -u $USER -t qemu0% sudo tunctl -u $USER -t qemu1% sudo brctl addbr br0% sudo brctl addif br0 qemu0% sudo brctl addif br0 qemu1% sudo ifconfig br0 192.168.222.1[dhcpd should listen on br0 and handle the 192.168.222.0/24 subnet]% sudo /etc/init.d/dhcpd restart% qemu -hda freelsd.img … -net nic,macaddr=00:11:22:33:44:55 -net tap,ifname=qemu0,script=no,downscript=no% qemu -hda openlsd.img … -net nic,macaddr=00:11:22:33:44:56 -net tap,ifname=qemu1,script=no,downscript=no
Michael, on Gentoo I can leave the tun/tap devices to be configured by OpenRC itself, the problem is that it still did’t seem to work, even using basically the same commands you gave me.But I solved using vde, now it works fine, but qemu doesn’t 😉