Hi, I don't think I've had substantial lags in VBoxes, but it may be a lucky case of hardware - and that's not only the different layers of virtualization support in CPUs. In particular, recent list mails suggested that server-grade NICs with buffers and networking-task offload features might implement things like CrossBow VNICs with their unique MAC addresses in hardware rather than with CPU emularion and brute promiscuous mode. Likewise, I believe it might be possible to find such hardware that would lag due to HW or (lack of) drivers in illumos, and you might have had bad luck with that on a particular motherboard. Thus, you might have better luck with separate NICs, usually those with e1000g driver pose almost no problems (during OS upgrades, they forget the Jumbo settings, if those were used, due to overwriting of /kernel/drv/e1000g.conf).
To verify that you hit VBox-intrinsic problems rather than something else, can you: 1) Set up an etherstub on the host and attach VM VNICs to that? This should rule out any hardware from your networking between VMs and host, leaving the VM engine performance and limitations. If this does work for you better than equivalent setup on hardware, you can organize routing/NAT via the host GZ or a dedicated LZ with exclusive IP stack attached to this etherstub. 2) You did set up the MAC addressing for bridged VM interfaces properly, right? (You have a dedicated host VNIC per VM NIC, and the unique MAC addresses of the two are equal) I did not really work with non-bridged interfaces (VBox NAT, VBox host-only), so can't comment on performance of those. 3) Recent VBox might add some optimizations like "memory balooning" and memory deduplication. I wonder if these happen to you, and if they are troublemakers or not... 4) Do you use the proprietary extension pack above the GPL VBox software, and do you add guest additions to your VM's OSes? Usually, these should help speed up your VM experiences. 5) Look in VBox logs (stored under VMs' folders), to see if the engine complains about anything unusual that it can't initialize or use, etc. 6) Scroll over VirtualBox under Solaris forum, perhaps ask some questions there too :) On another hand, I don't think I've stressed my systems that much. Basically, for an interactive VM I've only used my laptop in the past few months, and when there were tests with a dualbooted Win7 (on its dedicated partition where it could native-boot from too) performance felt acceptable. It did take slower to boot and halt, that with a native boot, but after I added RAM (and about 3Gb of the 8Gb available got dedicated to the Windows VM), performance during work (word processing, browsing) was not really discernible from that with a native boot with 4GB HW RAM before. Windows is memory-greedy however, so anything around 2GB lagged even on HW native boots for Win7 and Vista. For virtualization purposes, you might also need to provision much swap space (at least as much as your VMs are configured to use as their vRAM), and disk performance/cache for the backing stores might matter - though you do say that is blazing fast. _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss