@Ian, If i understand the bug report correctly, this would seem to be a generic bug regarding the default networking option setup as part of libvirt. If this is the case, I agree it's not a great ideal for servers - but also not an unreasonable default for the platform as a whole use case.
The default network provided for kvm, for example is:
$ cat /etc/libvirt/qemu/networks/default.xml
<network>
<name>default</name>
<bridge name="virbr%d" />
<forward/>
<ip address="192.168.122.1" netmask="255.255.255.0">
<dhcp>
<range start="192.168.122.2" end="192.168.122.254" />
</dhcp>
</ip>
</network>
I haven't checked for other virtulisation methods, but I imagine it is similar. It is easy enough to provide a chosen networking model, so I'm not fully convinced this is a valid bug.
Please can you confirm I have understood the bug report correctly.
@Ian, If i understand the bug report correctly, this would seem to be a generic bug regarding the default networking option setup as part of libvirt. If this is the case, I agree it's not a great ideal for servers - but also not an unreasonable default for the platform as a whole use case.
The default network provided for kvm, for example is: qemu/networks/ default. xml default< /name> "192.168. 122.1" netmask= "255.255. 255.0"> 192.168. 122.2" end="192. 168.122. 254" />
$ cat /etc/libvirt/
<network>
<name>
<bridge name="virbr%d" />
<forward/>
<ip address=
<dhcp>
<range start="
</dhcp>
</ip>
</network>
I haven't checked for other virtulisation methods, but I imagine it is similar. It is easy enough to provide a chosen networking model, so I'm not fully convinced this is a valid bug.
Please can you confirm I have understood the bug report correctly.
Thanks.