Hello,
Yes, our use case is not obvious
Let me try to explain it.
We have hosts (nodes of a private cloud) that are generic stripped down-optimized-VirtualBox servers, located at several dedicated servers hosting providers.
We have virtual machines (guests) which are designed to be host network independent, in order to be relocated at will, without any change.
Guests are known to the outside world only by their name(s).
We have name servers that make the matching between guests names and guest IP addresses, with short time-to-live caching delays, in order to be able to quickly point a guest name to a new guest IP address.
With NATed guests, we have no problem:
- they don't need to know their external IP address and are happy with their 10.0.2.15 internal address.
- they are configured to use DHCP, and get their internal IP address, network mask and DNS servers that way (nothing is hardwired).
- the host assigns them a specific (failover) IP address, makes some port forwarding (the ports we want to be visible to the outside world), sets some firewall rules (the ports we want to restrict to specific networks or IP addresses) and VPN tunnels (with specific networks).
With Bridged guests, it's more complicated:
- at dedicated servers hosting providers, we usually can't directly use virtual MAC addresses or our servers get banned.
- if we previously declare that a failover IP address will be using a virtual MAC address, it's allowed at some hosting providers
(for examples: see
http://guides.ovh.com/DedieMac /
http://guides.ovh.com/BridgeClient /
http://documentation.online.net/fr/serv ... p-failover /
http://www.online.net/serveur-dedie/adr ... elle.xhtml /
http://forum.online.net/index.php?/topi ... irtuelles/ ).
- but the solution involves knowing in the guest the external (failover) IP address, external IP address of the gateway and name servers, as well a setting some static routes.
- we don't want to hardwire these information because we still want to be able to relocate these guests at will.
[I've not yet tried what follows, but I will in the next weeks]
- the solution would be to provide all these information through DHCP. According to RFC2132 and RFC3442 (
http://tools.ietf.org/html/rfc2132 /
http://tools.ietf.org/html/rfc3442) it should be possible to provide all the information above to a guest (including static routes).
- I think I could do that with ISC DHCPD and some others, but I would prefer to use the internal DHCP server even if it's not sophisticated enough yet to use all the needed DHCP options (a mapping file would be sufficient for what I intend to do, and would avoid launching another process just for that).
- of course, the DHCP requests and offers would have to be filtered by the host firewall in order to stay inside that server.
- from the host, a virtual MAC address would be assigned to the guest.
- the failover IP address that we want for that guest would be associated to that virtual MAC address.
- thus, we wouldn't have to change the DNS information at each guest launch because of an unwanted IP address change, and the guest would stay completely unaware of its network environment and of the fact that it's used through NAT or bridge (whatever the OS installed inside it).
So, it's not that I want a guest to have or be aware of a specific IP address, but I'm currently obliged to do it because of the way hosting providers are handling VPS inside the dedicated servers that they provide. And the whole point of our private cloud is to be able to relocate guests at will between our different providers and/or our internal nodes...
Best regards,
Hubert