Re: [libvirt-users] firewalld, no dhcp and virsh
On 01/16/2013 12:27 AM, Paul Wouters wrote:
On all of the networks I create, I really don't want
libvirt/KVM/virt-manager to do any kind of DHCP. I'm currently using
xml files to feed into libvirt via virsh, for example:
<network>
<name>192_0_1</name>
<bridge name='swan01' stp='on' delay='0' />
<mac address='12:00:00:16:16:BA'/>
<ip address='192.0.1.127' netmask='255.255.255.0'>
</ip>
</network>
Running this through virsh net-define gives no errors, and
virt-manager shows:
DHCP Start: disabled
DHCP End: disabled
But any attempt at starting the network causes:
Error starting network '192_0_1': failed to add iptables rule to allow
DHCP requests from 'swan01'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in
tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/network.py", line 82, in
start
self.net.create()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2049, in
create
if ret == -1: raise libvirtError ('virNetworkCreate() failed',
net=self)
libvirtError: failed to add iptables rule to allow DHCP requests from
'swan01'
I narrowed this down to the fact that firewalld was not running.
So I guess there are two bugs:
1) when not specifying dhcp ranges in the xml, it should _not_ try to
poke DHCP holes.
I think probably the assumption when that code was written (and it's
been there for a very long time) was that, even if libvirt didn't setup
a dhcp server, the admin was likely to setup their own. And possibly
they were also concerned that independently adding your own dhcp rule in
the case that you also setup your own external dhcp server could end up
with libvirtd's REJECT rule for the network blocking the dhcp packets
before they could ever be allowed (depending on whether the rules were
added before or after libvirtd was started).
However, when I look at the rules today (on a Fedora 17 system), it
doesn't look that way. libvirt only REJECTs in the FORWARD table, not in
the INPUT table (where the rule to allow incoming dhcp would be added).
The real problem today, of course, is that making this rule conditional
is changing the behavior of libvirt in a way that could break a working
config on upgrade, and that's generally not well accepted. Does anyone
else have an opinion on this?
2) when firewalld is not running, it should perhaps log a warning,
but
not abort the network start.
As far as I've seen (on Fedora 17 and Fedora 18), if firewalld isn't
running, libvirtd will still start, and will start its networks too - it
just directly calls iptables, rather than going through firewalld
(firewall-cmd).
What is your platform, and what version of libvirt are you running?