https://bugzilla.novell.com/show_bug.cgi?id=863182 https://bugzilla.novell.com/show_bug.cgi?id=863182#c1 --- Comment #1 from Olaf Martens <olafmartens@web.de> 2014-03-30 03:56:47 UTC --- As an addition to this the <dhcp> element could receive an option to accommodate for the use of an external DHCP client (e. g. <dhcp external='dhcpd'/>). The reason behind this: When setting up virtual networks these interfaces are started way after the physical network has been brought up (and also after the dhcpd has already been started). In order to make it easier to use an external DHCP daemon this variant of a DHCP definition for libvirt would cause it to restart the DHCP daemon once all virtual interfaces have been brought up in dom0 and subsequently restart the DHCP daemon. This avoids a manual restart of the DHCP daemon to attach it to the virtual interfaces, because for some reason an attempt to order dhcpd.service (which on top of that still relies on System V Init instead of systemd) and libvirtd.service still causes any virtual interfaces to be brought up too late for dhcpd. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=863182 https://bugzilla.novell.com/show_bug.cgi?id=863182#c3 --- Comment #3 from Olaf Martens <olafmartens@web.de> 2014-08-31 14:17:42 CEST --- First of all, resorting to a routed instead of a bridged network configuration has the advantage that one has more control over the data traffic taking place - since the virtual interface is a separate network interface, it can be assigned to any firewall zones separately. Furthermore, the DHCP daemon is running on dom0 on the same machine that does the virtualization (maybe there's a misunderstanding here: With "external" I was referring to the DHCP daemon not being launched by libvirtd, but instead getting fired up stand-alone). If the DHCP server had been running on another machine, I would have resorted to the DHCP relay server instead... Since I'm already using dhcpd for serving any DHCP queries arriving at some of the physical interfaces it would be sensible to use that one to serve any DHCP requests from the virtual interface, too. So, FYI, here's what the network configuration looks like (using old-style identifiers for the sake of simplification): eth0 ---> Ethernet card, link to a subnet (uses dhcpd) wlan0 ---> Wireless adapter, link to a remote AP (starts dhcpcd to obtain an IP address) wlan1 ---> Wireless adapter, local AP in dom0 (uses dhcpd) veth0 ---> Virtual network, subnet for any VMs The point is that libvirtd is firing up an instance of dnsmasq when it brings up veth0 - however, since I have already set dhcpd up so that it serves any DHCP requests from the virtual network, dnsmasq is conflicting with dhcpd and therefore refuses to start. So, now my question is what exactly do you need (ifconfig output, config files, anything else)? That way I could provide the info all at once in order to avoid repeated requests... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=863182 https://bugzilla.novell.com/show_bug.cgi?id=863182#c5 Olaf Martens <olafmartens@web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|olafmartens@web.de | --- Comment #5 from Olaf Martens <olafmartens@web.de> 2014-09-02 15:36:53 CEST --- <network> <name>routed</name> <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid> <forward mode='route'/> <bridge name='veth0' stp='on' delay='0'/> <mac address='xx:xx:xx:xx:xx:xx'/> <ip address='192.168.127.1' netmask='255.255.255.0'> </ip> </network> I had to use bridged mode here, because networked mode won't work. The bridge is attached to dom0 by a virtual NIC. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.