1

Hey, I have a Debian Squeeze host with three Lenny VM's on VirtualBox.

  • formerly each system had its own public IP and the guests were just bridged
  • but now on a new box I will only get one physical IP and I do not know how to setup the network.

The guest VM's have several domains (http/https) and I should be able to directly access them by ssh.

I was thinking to give the guests a fixed internal IP and then mod_proxy from the host. And for ssh using port forwarding. Unsure about the network mode, can I use the 'bridged networking' with a non-public IP?

Would be great if someone could comment on this and/or give a link where such a setup is explained further.

Thanks a lot, Hans-Peter

2 Answers 2

1

What I would do is setup some type of reverse proxy on the main IP of the server. This would then route requests over either a host-only or bridged network connection. You should have no issues using bridged networking with non-public IPs.

Whatever you do, don't try to use NAT (At least VirtualBox's implementation). I've found that the performance of it is awful, and it's got some bugs that mean you have to regularly reboot the machine to keep networking working.

0

I was going to recommend just changing to NAT. I have not seen the performance problems with NAT unless you haven't installed the guest additions. Some people find it easier to create a separate Virtual client (often with X gui) to compile the additions and then copy to virtual servers to reduce the overhead of compilers, etc. on each of the server virtuals.

Port forwarding is simple through vboxmanage, many examples out there, here's the first one I found. just type vboxmanage to get the current syntax. It changes with VBox version updates. http://sk.c-wd.net/wp/2008/01/05/virtualbox-port-forwarding-with-linux-host/

Build a lenny virtual with gui, install guest additions, copy network drivers to lenny virtual servers. You may also copy other drivers if needed but usually I run my vbox virtuals servers headless and turn off copy paste buffer support in virtual client config. All access to virtual is through network. (ssh for terminal, IP/ports for services) You won't need to use the lenny gui virtual until the next Virtualbox update or the next lenny kernel update when you'll need to compile again and distribute the updates.

A system like this is great for all updates. Update and test on gui client then use as a local apt repo to distribute to virtual servers. Or remove apt completely from servers and use a custom update procedure.(puppet/SVN/rsync/etc.) Useful for "hosting" virtualization.

Our custom server virtuals match our deployed co-located systems and have no terminal support. It greatly reduces the number of exploits available. SSH file transfer access only. No VT's. No video cards. Multiple machines serial consoles are routed to a single admin machine to read boot messages if hardware doesn't have IPMI support. Hardware + software watchdogs to reboot and restart services. Some systems are smaller than 30mb for the service apps (+ kernel and data if needed). Just an example of modern systems built small, Microcore linux 3.6 is 6.8mb, tinycore is 11mb with gui.

Here is a link to the NAT port forwarding section of the Virtualbox Manual. http://www.virtualbox.org/manual/ch06.html#natforward

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .