Start VM with host interface networking from drifferent Linux user.

[leo]

I have a Linux user, that we call "user1", which runs several VM simultaneously using host interface networking. Wonderful (actually the introduction of host interface networking in 2.1.0 has been an amazing feature!).

Now another user, "user2", wants to run his own VM. The problem is that with NAT networking the VM starts and works correctly, but if I select HOST networking it fails to start with the following error:

Failed to open/create the internal network 'HostInterfaceNetworking-eth0' (VERR_PERMISSION_DENIED). Unknown error creating VM (VERR_PERMISSION_DENIED).

Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole {e3c6d4a1-a935-47ca-b16d-f9e9c496e53e}

[leo]

VM logfile

[rf]

Hi all, hope we can help others with the way we use to solve the above discussed problem.

Problem:

When: User-1 has a running VM with bridged network Interface-A (i.e. eth0, br0, whatsoever) Then: User-2 can not start another one VM with bridged networking Interface-A

Errormessage like:

Failed to open/create the internal network 'HostInterfaceNetworking-eth0' (VERR_PERMISSION_DENIED). Unknown error creating VM (VERR_PERMISSION_DENIED).

VirtualBox Versions:

This problem was true for us in all versions of VirtualBox 2 up to 2.2.2. (we still use this)

Remark:

The solution given in ticket #2852 with VBoxManage setextradata VM_NAME VBoxInternal/Devices/pcnet/0/LUN#0/Config/RestrictAccess 0 / VBoxManage setextradata VM_NAME VBoxInternal/Devices/pcnet/0/LUN#0/Config/RestrictAccess false did not work for us

Now one possible solution we use since months:

For each user that want start a VM make tap-devices bridged to your desired network interface, i.e. tapuser1 and tapuser2. You can use "tunctl" for this. We use Fedora FC10 and made us a patch to the ifup-eth/ifdown-eth scripts (Type="Tap") In the upcoming FC11 seems to be included a very similar patch, so we will use this in future. In VirtualBox the User1 in his VM now selects the bridged interface "tapuser1", and the User2 in his VM similarly the "tapuser2".

Just to complete the idea here excerpts of the patches and some example network interface files: /etc/sysconfig/network-scripts/ifup-eth: @@ -54,16 +54,6 @@

fi

fi

+if [ "${TYPE}" = "Tap" ]; then + if [ ! -x /usr/sbin/tunctl ]; then + echo $"TUN/TAP support not available: tunctl not found" + exit 1 + fi + if [ ! -d /sys/class/net/${DEVICE} ]; then

+ /usr/sbin/tunctl -g ${GROUP} -t ${DEVICE}

exit 1

+ fi +fi +

if [ "${TYPE}" = "Bridge" ]; then

if [ ! -x /usr/sbin/brctl ]; then

echo $"Bridge support not available: brctl not found"

/etc/sysconfig/network-scripts/ifdown-eth: @@ -144,12 +144,4 @@

fi

fi

+if [ "${TYPE}" = "Tap" ]; then + if [ ! -x /usr/sbin/tunctl ]; then + echo $"TUN/TAP support not available: tunctl not found" + elif [ ! -d /sys/class/net/${DEVICE} ]; then + /usr/sbin/tunctl -d ${DEVICE} + fi +fi +

exit $retcode

/etc/sysconfig/network-scripts/ifcfg-br0: # Bridge device DEVICE=br0 TYPE=Bridge ...

/etc/sysconfig/network-scripts/ifcfg-eth0: ... BRIDGE=br0

/etc/sysconfig/network-scripts/ifcfg-tapuser1: # TAP device DEVICE=tapuser1 TYPE=Tap GROUP=vboxusers ... BRIDGE=br0

/etc/sysconfig/network-scripts/ifcfg-tapuser2: # TAP device DEVICE=tapuser2 TYPE=Tap GROUP=vboxusers ... BRIDGE=br0

Hope this helps :-)

[rf]

Dear VirtualBox developers,

we just give a workaround for the problem addressed here.

Nevertheless, we see this problem as a bug in VirtualBox and bet you to solve it.

It should be possible for all users of a VirtualBox machine to use host networking with the same network interface. Your graphical user interface already allows to do this, it just does not work for different users running VMs concurrently.

By the way, in VMWare this is possible without problems.

Thank you very much,

kind regards

[Markus Wolff]

I can confirm this bug with VirtualBox 3.0.4 on Ubuntu Server 64bit as host and Ubuntu Server 32bit (minimal) as guest and bridged networking.

What I wanted to achieve is that each user on the box can run his own VM. The first user can start the VM fine, the next users trying to start theirs will then get the described error message. The workaround for now being that all VMs must be run by the same user, meaning all files touched by the VM have the same ownership. Not a satisfactory solution.

It would be great if this could be fixed.

[Markus Wolff]

Forgot to mention the Ubuntu version: 9.04

[Frank Mehnert]

Another workaround is to setup a host bridge and to attach tun/tap devices to the bridge, each user with its own tun/tap device. Not very elegant but it works.

[FengZhaolin]

The workaround provided by frank works for me. The detailed steps is (under ubuntu):

1. create a tap0 virtual network device

​http://manpages.ubuntu.com/manpages/karmic/man8/tunctl.8.html

\> sudo tunctl
set 'tap0' persistent.

2. edit /etc/network/interfaces, create a bridge between eth0 and tap0.

\> sudo vim /etc/network/interfaces

add:

iface br0 inet static

bridge_ports eth0 tap0

The final file on my machine is:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.0.143
        netmask 255.255.252.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1

iface br0 inet static
        bridge_ports eth0 tap0
        address 192.168.0.143
        netmask 255.255.252.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1

3. Turn off eth0.

sudo ifdown eth0

4. Turn on br0.

sudo ifup br0

5. Then, open the guest configuration, configure a the bridged network through 'tap0'. Not the default 'eth0' or 'vnet0'.

6. Start the guest, it should work now.

[Klaus Espenlaub]

This is a duplicate of #2852 - and the (revised) solution there definitely works.

We don't really consider this to be a bug, as the default behavior of VirtualBox is meant to be secure (unlike the other mentioned product) and doesn't allow users to spy on each other by being able to inspect low level network traffic.