mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-15 16:11:32 +00:00
013427e6e7
Normally dnsmasq will send a default route (the address of the host in the network definition) to any client requesting an address via DHCP. On an isolated network this makes no sense, as we have iptables to prevent any traffic going out via that interface, so anything sent that way would be dropped anyway. This extra/unusable default route becomes problematic if you have setup a guest with multiple network interfaces, with one connected to an isolated network and another that provides connectivity to the outside (example - one interface directly connecting to a physical interface via macvtap, with a second connected to an isolated network so that the host and guest can communicate (macvtap doesn't support guest<->host communication without an external switch that supports vepa, or reflecting all traffic back)). In this case, if the guest chooses the default route of the isolated network, the guest will not be able to get network traffic beyond the host. To prevent dnsmasq from sending a default route, you can tell it to send 0 bytes of data for the default route option (option number 3) with --dhcp-option=3 (normally the data to send for the option would follow the option number; no extra data means "don't send this option"). I have checked on RHEL5 (a good representative of the oldest supported libvirt platforms) and its version of dnsmasq (2.45) does support --dhcp-option, so this shouldn't create any compatibility problems.
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>