| Summary: | Feature request: allow to create two private virtual networks using the same subnet | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Éric Bischoff <ebischoff> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | ebischoff, laine, rbalakri |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-24 01:59:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Both of these subnets would be connected to the host with an IP address, and the host would thus need routing to them (even an isolated network must be able to communicate with the host, since that's where the dhcp and dns servers are).
The only way I can think of that this would work is if each network was placed in a separate network namespace, so that the routing domains were disjoint. That might actually be a useful, but would likely require running dnsmasq in a container (?)
Alternately you would just configure the network to have *no* IP address on the bridge, and run a dnsmasq on a guest connected to the network - this can be done with no addition to libvirt - just define the networks like this:
<network>
<name>netname</name>
</network>
Hi Laine, and thanks for that detailed answer. Let me explain better my use cases: 1 - I have tests where I have static IP assignement for all interfaces (no DHCP and DNS at all). 2 - I have other tests where I provide myself the DHCP server myself, on one of the VMs, inside the isolated networks (and no DNS as I'm cut from the outside). 3 - finally, I have tests where I would need libvirt's DHCP possibilities, but still do not need communications to the outside (no routing, no DNS). Having no IP address on the bridge solves use cases 1 and 2, but not use case 3: that is the difficult one. The namespace solution would certainly be helpful to many people, but it sounds overcomplicated for the needs above. Can't you just run dnsmasq on an interface to provide DHCP, without doing any routing? For example, can't dnsmasq work with an interface with no IP address assigned to it? I did not check, but the documentation suggests it could work when using interface=<interface> instead of listen=<address> in dnsmasq's configuration. Or you could assign an IP address to the bridge on the host, but make it a /32, that would make it belong to a standalone network. Different IP addresses for the bridge could be chosen manually in the configuration of the various networks to avoid duplicates. OK, I tested: We can't use two dnsmasq processes just listening on bridge interfaces without addresses: "dnsmasq: failed to bind to DHCP server socket: Address already in use", A netstat confirms they would both try to listen to 0.0.0.0:53, which is impossible. I suppose a similar problem would occur with different dnsmasq processes trying to listen to 172.16.0.0:53, even when the address on the host is a /32. Remains the namespace solution, but... argh. That's sad, because it prevents to test twice with the same network setup on "isolated" networks, while keeping a DHCP address broker. Without DHCP, it works as you indicated. Feel free to close as WONTFIX. Thanks for taking the time to test your idea. |
Description of problem: Feature request: add an option to let creation of two virtual networks using the same subnet. This new "I know what I am doing" option could be an option to the virsh command, for example: --allow-identical-subnets It could also go to the XML configuration, that does not matter. For example: <reuse-subnet>true</reuse-subnet> or <unique-subnet>false</unique-subnet> Version-Release number of selected component (if applicable): /usr/sbin/libvirtd (libvirt) 2.1.0 How reproducible: libvirt daemon and utilities installed, configured and started. Steps to Reproduce: 1. create two XML files defining two different private networks 2. make sure they use the same subnet, for example 172.16.0.0/16 3. try to virsh net-define and virsh net-start the networks Example configuration files: <network ipv6='yes'> <name>private1</name> <uuid>18571481-2c9b-47b4-9706-c71d1a3d76ab</uuid> <bridge name='private1br0' stp='off' delay='0'/> <mac address='52:54:00:13:a6:1a'/> <ip address='172.16.0.0' prefix='16'> </ip> </network> and similar for private2. Actual results: The second network won't start, with error message "error: internal error Network is already in use by interface " followed by the name of interface of first network. Expected results: The second network would start. Additional info: Such an error is normal in a production environment, where those networks would be interconnected, and where it makes no sense to have two identical subnets. This error message catches quite a lot of configuration mistakes, and is therefore a good thing. However, in a testing environment, when the networks are isolated from each other (no routing between them), it makes perfect sense to use the same subnet range, even with DHCP. This new feature would allow to run the same test in parallel twice with identical setups on isolated private networks. I have also seen in forums that refusal to use the same subnet can create problems when manipulating snapshots (not experienced myself though). This option would also be helpful in that context.