Page 1 of 2

Bind separte PHYSICAL interface to VM

Posted: 4. Sep 2008, 17:44
by Angry
I've read about bridging a VM to the host o/s's and the bridge should give the vm a separate address so you can easily remote into it or even have it accessed by clients as if it were a separate server (like web, vpn, ftp services).

But how do you bind the VM to a separate PHYSICAL interface? My machine has two extra NIC's and I'm on a campus that issues public addresses. I'd like to bind the VM to one of the interfaces that is not used by the host O/S. Is that dooable? Has anyone ever done this? Please let me know if you need any additional information.

Posted: 4. Sep 2008, 19:20
by Sasquatch
You bridge the connection to a physical interface, there is no other way to get your VM to be a part of the network. You can select which interface you add to the bridge. If you have Interface A that you use for Campus and Interface B for private networking, and you want your VM to be a part of the Campus network, bridge Interface A with a virtual interface set to the VM. Of course, the other way around is also possible, make the VM part of your private network ;).

Posted: 7. Sep 2008, 13:54
by Angry
Thanks for the reply, Sasquatch. I do appreciate you taking the time to reply and I found my answer. The keywords I'm looking for are "Permanent Host Interface Networking" and I found it in the VBox user manual. It was all there, just need the proper keyword to search.

I did bridge the NIC's per the documentation, but now I'm having some weird issues.

This is a high-level diagram for project I'm doing:
Image

I want eth1 to be used by the host o/s (Ubuntu 8.04) and the VM's to use eth0 and eth4, respectively. This way I can still use the campus network and keep the VM's on their own network.

One of the VM's runs a dhcp server, so sometimes it allocates an IP address and other information to my host o/s and I really don't want it to do that. I want it to allocate that information to the other VM (and other machines on the lab network but that's beside the point). Each VM is set to the name of the bridged, virtual-to-physical interface per the Virtualbox documentation:

eth0 is bridged to vbox0 and is named br0
eth4 is bridged to vbox1 and is named br1

Here's a copy of my ifconfig:

Code: Select all


rt3@rt3-desktop:~$ ifconfig
br0       Link encap:Ethernet  HWaddr 00:0a:5e:54:c0:3a  
          inet6 addr: fe80::20a:5eff:fe54:c03a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:905 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:65863 (64.3 KB)  TX bytes:12051 (11.7 KB)

br1       Link encap:Ethernet  HWaddr 00:0a:5e:54:c0:14  
          inet addr:10.10.1.3  Bcast:10.10.1.255  Mask:255.255.0.0
          inet6 addr: fe80::20a:5eff:fe54:c014/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:90443 errors:0 dropped:0 overruns:0 frame:0
          TX packets:311 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:25758901 (24.5 MB)  TX bytes:41201 (40.2 KB)

br0:avahi Link encap:Ethernet  HWaddr 00:0a:5e:54:c0:3a  
          inet addr:169.254.5.229  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0      Link encap:Ethernet  HWaddr 00:0a:5e:54:c0:3a  
          inet6 addr: fe80::20a:5eff:fe54:c03a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:101364 errors:0 dropped:0 overruns:1 frame:0
          TX packets:1487 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:28549702 (27.2 MB)  TX bytes:400188 (390.8 KB)
          Interrupt:21 Base address:0x2880 

eth1      Link encap:Ethernet  HWaddr 00:19:d1:7e:4e:84  
          inet addr:136.204.168.136  Bcast:136.204.171.255  Mask:255.255.252.0
          inet6 addr: fe80::219:d1ff:fe7e:4e84/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:228101 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53714 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:41094810 (39.1 MB)  TX bytes:33335166 (31.7 MB)
          Base address:0x30c0 Memory:90300000-90320000 

eth4      Link encap:Ethernet  HWaddr 00:0a:5e:54:c0:14  
          inet6 addr: fe80::20a:5eff:fe54:c014/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:97424 errors:0 dropped:0 overruns:1 frame:0
          TX packets:877 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27602626 (26.3 MB)  TX bytes:95038 (92.8 KB)
          Interrupt:23 Base address:0xa800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1491 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1491 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:78336 (76.5 KB)  TX bytes:78336 (76.5 KB)

vbox0     Link encap:Ethernet  HWaddr 00:ff:b5:88:b8:ca  
          inet6 addr: fe80::2ff:b5ff:fe88:b8ca/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:562 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4601 errors:0 dropped:87935 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:66952 (65.3 KB)  TX bytes:1073968 (1.0 MB)

vbox1     Link encap:Ethernet  HWaddr 00:ff:d3:37:28:fe  
          inet6 addr: fe80::2ff:d3ff:fe37:28fe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1936 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2014 errors:0 dropped:87053 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:176744 (172.6 KB)  TX bytes:191955 (187.4 KB)

rt3@rt3-desktop:~$

Posted: 7. Sep 2008, 20:22
by Sasquatch
Check the man page for the interfaces file. You might want to set a static IP of 0.0.0.0 on the bridges, so they act as a transparent interface, leaving out the Host OS of it's use.

Posted: 7. Sep 2008, 20:55
by Angry
There's no man page for bridge-utils. I don't see why setting all 0's would leave out the host O/S - can you explain in more detail?

One thing I wondered - does eth0 and vbox0 HAVE to be bridged to br0 because I have eth1 and vbox0 bridged to br0 simply because of the way Ubuntu named my physical interfaces.

EDIT: I found this link that I'll see if I can get read in time. If you have any other thoughts I would appreciate them because it's really important that I get this done by Tuesday night. Thanks!

Posted: 7. Sep 2008, 21:14
by Sasquatch
The interface names don't matter when adding them to a bridge. I have my bridge called brdg and have the interfaces lan, vbox0, vbox1 and vbox3 in it.

The man pages I was referring to is man interfaces. If you set an IP address of 0.0.0.0 you give it an empty address. See other options for interface configurations in the man page. I know that there is dhcp, static and manual. Setting it to DHCP will give it an address from your Guest VMs DHCP server, something you don't want.

Good luck.

Posted: 7. Sep 2008, 22:44
by Angry
Ok, thanks. I have some other things I have to do and maybe tonight or tomorrow afternoon I'll get a chance to read up on that. What you stated certainly makes sense.

Edit: You know one thing that is bothering me is not necessarily the IP address of the Guest DHCP server, but the DHCP server is also telling my host o/s what nameservers to use which is really a problem. I apologize - because I don't think it was the IP address that was changing, but instead of resolv.conf containing the campus network nameservers, it started to wipe those out and include the addresses of the nameservers from the Guest DHCP server. I'll still read what you suggested (perhaps there's a parameter in interfaces to keep it from updating resolv.conf) but I recall now that that was a big issue. Suddenly, I couldn't get name resolution for package managers finding repositories like apt because they were trying to resolve from nameservers that weren't connected to the internet.

Posted: 7. Sep 2008, 22:55
by Sasquatch
I will be here on the evenings on EST times (GMT +1). If there are some more issues, I can answer them tomorrow evening.

Posted: 7. Sep 2008, 22:55
by Angry
Wow thank you very much - check my update from the previous post :) Do you ever hang in the IRC channel?

Posted: 7. Sep 2008, 23:04
by Sasquatch
Nope, if I would do that, I don't have any more spare time left. And that is limited now that I hang here as a moderator. It took more than 2 hours to catch up for today.

The fact that your /etc/resolv.conf is rewritten is because you got a new DHCP address. If you would update your Campus address, it will be back again. However, I personally find that a pain to do each time you start a VM after it finishes loading. I would go for the static address config with 0.0.0.0. Gonna check on my VM now if that actually works ;). Be back here in a few min.

Posted: 7. Sep 2008, 23:16
by Angry
Cool, thanks :) Take your time and if I don't get any more time to troubleshooot this tonight (gotta study for other stuff tomorrow) I'll see you later tomorrow evening. I appreciate all your help in guiding me to the right answer.

Posted: 7. Sep 2008, 23:33
by Sasquatch
Ok, I've just set the IP with static to 0.0.0.0 netmask 255.0.0.0 and no problems bringing the interface up. Looks like that is your solution. That way, your bridge and Host won't be part of the test network your VMs are part of. You can set an IP address manually using the ifconfig command if you need to access the test network from the Host using IP addresses only.

Posted: 7. Sep 2008, 23:41
by Angry
Um, is this essentially shutting off the interface so only the other two interfaces work? The idea is to make the campus-network facing interface a management interface so I can VNC into it, then manipulate the VM's to do whatever they need to on the lab network. Hope you don't mind me asking you questions until I've read the documents but if you're still around I thought I'd ask.

Posted: 7. Sep 2008, 23:45
by Sasquatch
Setting the IP of 0.0.0.0 to a bridge interface (br0) will make the bridge stay out of the network and work transparently. You still have all the options for the test network, your host is just not a part of it, only the VMs and the other machines on that network until you set an IP address on the bridge interface like it does with the DHCP setting and overwrites your /etc/resolv.conf.

Posted: 7. Sep 2008, 23:49
by Angry
Thank you! I'll let you know how mine goes probably tomorrow and I'll be sure to read that documentation you suggested. Thank you again. Do you maintain any open-source projects that allow donations ? :)