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
[email protected]
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.
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
