[OpenIndiana-discuss] CIFS performance issues

[Robin Axelsson]

On 2012-01-26 09:32, Open Indiana wrote:
> Please skip the whole ifconfig and plumb this or that discussion.
>
> Virtualbox works on any interface that is "plumbed" since only then the
> interface is visible in the menu. A working IP-adress is not necessary.
> Please put your interfaces on manual IP-assignment and disable nwam.
> Give an IP-address to 1 interface so you can manage your host-server.
>
> A bridged interface in VirtualBox just means that VB allows all traffic to
> go directly to your VM client.
>
> So:
> 1. disconnect all ethernetcables from the hostserver
> 2. put one back in an interface
> 3. login to the server
> 4. disable nwam
> 5. give the online interface a working IP-configuration via ifconfig /
> nsconfig / nslookup config files
> 6. make sure no configuration for the other interfaces is to be found inside
> /etc
> 7. plumb up a free interface by ifconfig and put a cable in this interface
> 8. start VirtualBox Gui
> 9. configure client to use the interface of point 7
> 10. start the client
> 11. grab some coffee
> 12. enjoy
>
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>

Are you really sure that only "plumbed" interfaces are visible in 
VirtualBox? All physical interfaces were still visible in VirtualBox 
even after I "unplumbed" them on my system. Perhaps their visibility 
depends on how you set up the virtual networking. In NAT mode, 
VirtualBox as I understand it communicates via the IP stack of the host, 
so it makes sense that in this mode, only the plumbed interfaces are 
visible to VirtualBox. However, in bridged mode as the documentation 
implies, the vboxflt driver goes past the IP stack so It would make 
sense that even the unplumbed interfaces should be visible in that mode. 
Remember that the NAT mode is the default networking mode in VirtualBox.

Normally I shouldn't really worry about this. I should be able to get 
away with only one network connection and the Bridged Network of the 
VirtualBox hypervisor should run seamlessly together with the host's IP 
stack on the datalink without hickups. But in reality this is not the 
case and nobody knows when these issues will be sorted out.

The vboxflt driver (which is the driver being used for bridged 
networking in VirtualBox ) is buggy. After every third boot or so, the 
VMs using this driver (i.e. bridged networking) fails to initialize. So 
I have to go superuser and rem_drv, add_drv the vboxflt driver to fix 
this issue and repeat this procedure every time the VMs fail.

So what I'm doing is isolating VirtualBox from the IP stack of the host 
and it seems to have worked for me. It isn't a complicated thing to do. 
All I had to do was to disable all NICs but one in the nwam properties 
window and then choose one of the disabled NICs for bridged networking 
in VirtualBox. The vboxflt driver still fails after every third boot but 
at least it doesn't interfere with the IP stack of the host.

But although this is not a complicated thing to do it is very useful to 
*know* what you are doing and understand the limitations of your system 
which I think James Carlson has provided good insights into.

One way to make the system user-friendly is to make nwam automatically 
configure IPMP when it detects two properly working ethernet connections 
within the same subnet. Perhaps it already does so. If not it should at 
least unplumb one connection to prevent the interference issues the 
James Carlson was talking about, or at least give warning messages about 
it. If we want to make it even more user friendly it could also have 
monitoring features (such as /sbin/route monitor) and offer some 
troubleshooting functionality or even warn about buggy drivers such as 
the rge driver.

I think it is a little strange that the Realtek RTL8111DL used to work 
well and now that I swapped to a Realtek RTL8111E everything went 
haywire. Maybe the drivers have been altered in some way in the 
development process of OpenIndiana, perhaps they have accidentally 
reverted to some old and buggy driver. I don't know about the 8111 chip 
but I believe that the D and E in the name/ID suggest that E is a later 
generation of the circuit and in the future we will expect to see an 
RTL8111F chip in production. The L merely denotes the type of 
encapsulation (PLCC) of the chip as it comes in different 
encapsulations.  When comparing generations it seems that the chip is 
essentially the same but is revised with some new features or fixes.

It is not the first time I've had this experience, I have experienced 
things that used to work well suddenly become buggy. In the past when I 
was running OpenSolaris b111 I had problems getting the ntfs-3g 
filesystem to work. But after compiling a recent version of fuse it 
worked fine. Then I updated OpenSolaris to b134 and once again it 
started to crash the system.

Robin.