On Fri, 17 Apr 2009, eprparadocs@gmail.com wrote:
Richard,
All the attributes you can give to a non-virtualized network should be available to the private virtualized network. For instance I might want to use DHCP to allocate addresses on a VM attached to it. Others might need a fixed IP address.
Indeed. However, I think that such matters can be easily solved if we maintain a strict "infrastructure provider" approach to the problem: Keeping the analogy of renting physical infrastructure in mind, I think it is completely sufficient to expose operations in the API for defining network membership (which clearly sets up virtual networks between VMs) and static IP addresses or "acquire via DHCP" for the actual interfaces. This is like specifying which cables to connect to which interface, which is a pure infrastructure-related issue. So, for instance: VM1: eth0 connected to "blue" network, static IP 192.168.0.1 eth1 connected to "red" network, DHCP VM2: eth0 connected to "blue" network, DHCP VM3: eth0 connected to "red" network, static IP 123.123.123.123 Using this approach, if the customer wishes to use DHCP (including one that makes use of all the magic in dhcpd.conf), he/she should deploy a VM that acts as the DHCP server in one of the networks (e.g. VM1 may act as the DHCP server for the "blue" network, which will assign an address to VM2). A pure DHCP server VM would require very little resources, and would therefore be very cheap to deploy. This keeps the interface small with few operations, while at the same time offers system administrators full flexibility in setting up their networks. -- Lars