Page 1 of 1

ONE bridged guest sucks life out of Solaris 10 Host

Posted: 25. Apr 2011, 23:00
by packetboy
Host running Solaris 10u9/VirtualBox 4.04....have massive CPU (dual, multi-core intel), 36GB of RAM. Essentially no real loads on the server.

I have a remote Fedora desktop (non-VM) that NFS mounts to the Solaris server.
Before I fire up a VirtualBox Guest, network performance is near 1Gbps:

Code: Select all

$ dd if=/mnt/cytel/temporary/VMware-VIRemoteCLI-3.5.0-104314.exe of=/dev/null bs=1M
40+1 records in
40+1 records out
42644344 bytes (43 MB) copied, 0.460363 s, 92.6 MB/s
Then I fire up an Ubuntu 10.10 (64bit) Guest on the Solaris server:

Code: Select all


# cat createvm2.sh 

VBoxManage createvm --name asterisk330 --memory 1000 --ostype Ubuntu_64 --register
VBoxManage storagectl asterisk330 --name "IDE Controller" --add ide
VBoxManage storageattach asterisk330 --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /rz2pool/virtualboximages/asterisk330/asterisk330.vdi
#VBoxManage modifyvm asterisk330 --nic1 bridged --bridgeadapter1 e1000g0
VBoxManage modifyvm asterisk330 --nic1 bridged --nictype1 virtio --bridgeadapter1 e1000g0
VBoxManage storageattach asterisk330 --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /rz2pool/isoimages/ubuntu-10.10-server-amd64.iso

(Note: Tried both e1000 (default) and virtio network drivers).

The VM come up and *sorta* works (e.g. it's an Asterisk voip server)...but it completley crushes local LAN performance. For example, here's the same NFS copy that was done just prior to launching the VM:

Code: Select all

$ dd if=/mnt/cytel/temporary/mysql-5.5.11-solaris10-x86_64.tar of=/dev/null bs=1M
^C15+0 records in
14+0 records out
14680064 bytes (15 MB) copied, 8.15993 s, 1.8 MB/s
If I reconfigure the VM to 'nat' instead of bridge and bring it up...NFS performance is good to go.

Unfortunately, running an Asterisk server behind an additional Layer of NAT is not really a lot of fun, so really would like to get bridged mode working.

Thoughts?

I'm almost thinking the 'bridge' is some how creating a loop and there is no spanning tree to prevent that...how can I see the details of the 'bridge' that VBox is creating...like you can do in KVM with 'brctl'?

Or does anyone have any ideas why the box is so destabalized by this VM...note: the problem even occurs if I set the VMs NIC to a 'disconnected' state.

Re: ONE bridged guest sucks life out of Solaris 10 Host

Posted: 5. May 2011, 10:57
by budy
I think I got the same behaviour on my Solaris box regarding COMSTAR iSCSI targets, that were configured on that Solaris box. As soon as I started the guest, which had a nic that was bridged on e1000g0, the iCSSI transfers slowed down to a crawl.

I solved that by using the 2nd nic on my Solaris box for VB guests.

Cheers,
budy

Re: ONE bridged guest sucks life out of Solaris 10 Host

Posted: 28. Oct 2016, 23:13
by timk6
2016 and bridged networking is still a complete disaster.

It worked fine up until 5.0, I never had a problem with it before, now I've wasted hours updating it after finding some promising bug reports, but still with no results.

Re: ONE bridged guest sucks life out of Solaris 10 Host

Posted: 2. Nov 2016, 11:25
by michaln
Well, with vague rant/complaints like that, and posting on long-dead threads, of course you can't expect much.

In general, if you have nothing factual to add, just don't. And no, "complete disaster" does not count.

Re: ONE bridged guest sucks life out of Solaris 10 Host

Posted: 2. Nov 2016, 16:43
by Ramshankar
Please provide reproducible steps illustrating the problem.
timk6 wrote:It worked fine up until 5.0, I never had a problem with it before, now I've wasted hours updating it after finding some promising bug reports, but still with no results.
As far as Solaris 10 goes, nothing has changed in the VirtualBox bridge networking area for years. It still uses the STREAMS networking driver written way back (probably in VirtualBox 2.0 or something). If you have some specific bugs with promiscuous mode behaviour, let us know what those are (or point to the existing bug reports).