10:23 p.m.
Hi.
I have a machine with a local DHCP server and a couple of virtual networks and
I've configured the server for each virtual interface, so that I would be able
to install VMs on the corresponding subnets using PXE.
The problem is that the two DHCP servers (my local server and dnsmasq) are
conflicting with each other causing the boot process to either fails or takes
ages untill a VM can catch the PXE parameters.
Note this output upon starting two VMs on two different subnets:
-----------------------------------------------------------------------------
tail -n1 -f </var/log/syslog | egrep -i "dhcpd|dnsmasq-dhcp"
Sep 13 05:11:25 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:25 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:26 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:26 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:27 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:27 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:28 host dhcpd: DHCPREQUEST for 192.168.100.251 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1: unknown lease 192.168.100.251.
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPACK(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:36 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:11:36 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:36 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:36 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:38 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:11:38 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107 52:54:00:2a:e0:a6
address not available
Sep 13 05:11:38 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:38 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:53 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:03 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107 52:54:00:2a:e0:a6
address not available
Sep 13 05:12:08 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:12:08 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107 52:54:00:2a:e0:a6
address not available
Sep 13 05:12:08 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
-----------------------------------------------------------------------------
So, is there a way to stop dnsmasq from starting automatically when starting
libvird? I haven't been able to see any trace of it in the init scripts, and my
guessing is that it's started not as a service, but in an ad-hoc manner by
libvirt-bin.
Checking the dependencies of the libvirt-bin package, I've noticed that
dnsmasq is among them. So, my question is whether, starting dnsmasq
automatically is something that is hard coded in libvirt-bin or is it just started
in some other way that I am not aware of?
Any suggestions would be really appreciated.
Thanks,
Marwan
12:04 a.m.
On 2012年09月13日 11:23, Marwan Tanager wrote:
Hi.
I have a machine with a local DHCP server and a couple of virtual networks and
I've configured the server for each virtual interface, so that I would be able
to install VMs on the corresponding subnets using PXE.
The problem is that the two DHCP servers (my local server and dnsmasq) are
conflicting with each other causing the boot process to either fails or takes
ages untill a VM can catch the PXE parameters.
Note this output upon starting two VMs on two different subnets:
-----------------------------------------------------------------------------
tail -n1 -f</var/log/syslog | egrep -i "dhcpd|dnsmasq-dhcp"
Sep 13 05:11:25 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:25 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:26 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:26 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:27 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:27 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:28 host dhcpd: DHCPREQUEST for 192.168.100.251 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1: unknown lease 192.168.100.251.
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:28 host dnsmasq-dhcp[1882]: DHCPACK(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:36 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:11:36 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:11:36 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:36 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:38 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:11:38 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107
52:54:00:2a:e0:a6 address not available
Sep 13 05:11:38 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:38 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:11:53 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:11:53 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPDISCOVER from 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPOFFER on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPREQUEST for 192.168.122.194 (192.168.122.1) from
52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:00 host dhcpd: DHCPACK on 192.168.122.194 to 52:54:00:72:f0:e2 via virbr0
Sep 13 05:12:03 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:03 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:12:06 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107
52:54:00:2a:e0:a6 address not available
Sep 13 05:12:08 host dhcpd: DHCPDISCOVER from 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPDISCOVER(virbr1) 52:54:00:2a:e0:a6
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPOFFER(virbr1) 192.168.100.251
52:54:00:2a:e0:a6
Sep 13 05:12:08 host dhcpd: DHCPOFFER on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPREQUEST(virbr1) 192.168.100.107
52:54:00:2a:e0:a6
Sep 13 05:12:08 host dnsmasq-dhcp[1882]: DHCPNAK(virbr1) 192.168.100.107
52:54:00:2a:e0:a6 address not available
Sep 13 05:12:08 host dhcpd: DHCPREQUEST for 192.168.100.107 (192.168.100.1) from
52:54:00:2a:e0:a6 via virbr1
Sep 13 05:12:08 host dhcpd: DHCPACK on 192.168.100.107 to 52:54:00:2a:e0:a6 via virbr1
-----------------------------------------------------------------------------
So, is there a way to stop dnsmasq from starting automatically when starting
libvird? I haven't been able to see any trace of it in the init scripts, and my
guessing is that it's started not as a service, but in an ad-hoc manner by
libvirt-bin.
Checking the dependencies of the libvirt-bin package, I've noticed that
dnsmasq is among them. So, my question is whether, starting dnsmasq
automatically is something that is hard coded in libvirt-bin or is it just started
in some other way that I am not aware of?
No, to disable the autostarting of dnsmasq, you need to disable the
autostart of network which drives dnsmasq (named 'default' by default).
% virsh net-autostart --disable default
Then it won't be started automatically along with libvirtd service next
time.
Regards,
Osier
1:55 a.m.
On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
On 2012年09月13日 11:23, Marwan Tanager wrote:
No, to disable the autostarting of dnsmasq, you need to disable the
autostart of network which drives dnsmasq (named 'default' by default).
% virsh net-autostart --disable default
Then it won't be started automatically along with libvirtd service next
time.
Thanks for the response, but my question was whether it's possible to start
libvirtd (and hence, activate the virtual networks "automatically") on boot, but
without dnsmasq being started along the way. Your answer means that to disable
dnsmasq from starting automatically, I need to disable the network form starting
automatically too.
Anyway, I destroyed the 'default' network, then killed the dnsmasq process for
that network, but when I started it again, dnsmasq started along with it. So, it
appears that the whole thing is hard coded.
So, would this solution have any side effects: To delete 'default' then recreate
it but without DHCP enabled?
Thanks,
Marwan
2:17 a.m.
On 2012年09月13日 14:55, Marwan Tanager wrote:
On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
> On 2012年09月13日 11:23, Marwan Tanager wrote:
>
> No, to disable the autostarting of dnsmasq, you need to disable the
> autostart of network which drives dnsmasq (named 'default' by default).
>
> % virsh net-autostart --disable default
>
> Then it won't be started automatically along with libvirtd service next
> time.
Thanks for the response, but my question was whether it's possible to start
libvirtd (and hence, activate the virtual networks "automatically") on boot,
but
without dnsmasq being started along the way. Your answer means that to disable
dnsmasq from starting automatically, I need to disable the network form starting
automatically too.
Anyway, I destroyed the 'default' network, then killed the dnsmasq process for
that network, but when I started it again, dnsmasq started along with it. So, it
appears that the whole thing is hard coded.
No, it depends on your previous network status, note that libvirt
saves the object's state, so that things could be consistent before
restarting/reloading.
# virsh net-list --all
Name State Autostart
-----------------------------------------
default active no
# service libvirtd restart
Restarting libvirtd (via systemctl): [ OK ]
# virsh net-list --all
Name State Autostart
-----------------------------------------
default active no
# pidof libvirtd
6868
# pidof dnsmasq
6826
# virsh net-destroy default
Network default destroyed
# service libvirtd restart
Restarting libvirtd (via systemctl): [ OK ]
# virsh net-list --all
Name State Autostart
-----------------------------------------
default inactive no
# ps -ef | grep dnsmasq
root 6762 20112 0 15:07 pts/1 00:00:00 grep --color=auto dnsmasq
# pidof libvirtd
6689
Does this make sense to you? :-)
Regards,
Osier
2:50 a.m.
On Thu, Sep 13, 2012 at 03:17:14PM +0800, Osier Yang wrote:
On 2012年09月13日 14:55, Marwan Tanager wrote:
>On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
>>On 2012年09月13日 11:23, Marwan Tanager wrote:
>>
>>No, to disable the autostarting of dnsmasq, you need to disable the
>>autostart of network which drives dnsmasq (named 'default' by default).
>>
>>% virsh net-autostart --disable default
>>
>>Then it won't be started automatically along with libvirtd service next
>>time.
>
>Thanks for the response, but my question was whether it's possible to start
>libvirtd (and hence, activate the virtual networks "automatically") on
boot, but
>without dnsmasq being started along the way. Your answer means that to disable
>dnsmasq from starting automatically, I need to disable the network form starting
>automatically too.
>
>Anyway, I destroyed the 'default' network, then killed the dnsmasq process
for
>that network, but when I started it again, dnsmasq started along with it. So, it
>appears that the whole thing is hard coded.
No, it depends on your previous network status, note that libvirt
saves the object's state, so that things could be consistent before
restarting/reloading.
# virsh net-list --all
Name State Autostart
-----------------------------------------
default active no
# service libvirtd restart
Restarting libvirtd (via systemctl): [ OK ]
# virsh net-list --all
Name State Autostart
-----------------------------------------
default active no
# pidof libvirtd
6868
# pidof dnsmasq
6826
# virsh net-destroy default
Network default destroyed
# service libvirtd restart
Restarting libvirtd (via systemctl): [ OK ]
# virsh net-list --all
Name State Autostart
-----------------------------------------
default inactive no
# ps -ef | grep dnsmasq
root 6762 20112 0 15:07 pts/1 00:00:00 grep --color=auto dnsmasq
# pidof libvirtd
6689
Does this make sense to you? :-)
Regards,
Osier
It does, but it's a different story. You should have tried two more commands
after the last one:
# virsh net-start default
# ps -ef | grep dnsmasq
then, you would have found the grepping positive. That's what I'am actually
talking about :)
Marwan
2:54 a.m.
On 2012年09月13日 15:50, Marwan Tanager wrote:
On Thu, Sep 13, 2012 at 03:17:14PM +0800, Osier Yang wrote:
> On 2012年09月13日 14:55, Marwan Tanager wrote:
>> On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
>>> On 2012年09月13日 11:23, Marwan Tanager wrote:
>>>
>>> No, to disable the autostarting of dnsmasq, you need to disable the
>>> autostart of network which drives dnsmasq (named 'default' by
default).
>>>
>>> % virsh net-autostart --disable default
>>>
>>> Then it won't be started automatically along with libvirtd service next
>>> time.
>>
>> Thanks for the response, but my question was whether it's possible to start
>> libvirtd (and hence, activate the virtual networks "automatically") on
boot, but
>> without dnsmasq being started along the way. Your answer means that to disable
>> dnsmasq from starting automatically, I need to disable the network form starting
>> automatically too.
>>
>> Anyway, I destroyed the 'default' network, then killed the dnsmasq
process for
>> that network, but when I started it again, dnsmasq started along with it. So, it
>> appears that the whole thing is hard coded.
>
> No, it depends on your previous network status, note that libvirt
> saves the object's state, so that things could be consistent before
> restarting/reloading.
>
> # virsh net-list --all
> Name State Autostart
> -----------------------------------------
> default active no
>
> # service libvirtd restart
> Restarting libvirtd (via systemctl): [ OK ]
>
> # virsh net-list --all
> Name State Autostart
> -----------------------------------------
> default active no
>
> # pidof libvirtd
> 6868
> # pidof dnsmasq
> 6826
>
>
> # virsh net-destroy default
> Network default destroyed
>
> # service libvirtd restart
> Restarting libvirtd (via systemctl): [ OK ]
>
> # virsh net-list --all
> Name State Autostart
> -----------------------------------------
> default inactive no
>
> # ps -ef | grep dnsmasq
> root 6762 20112 0 15:07 pts/1 00:00:00 grep --color=auto dnsmasq
> # pidof libvirtd
> 6689
>
> Does this make sense to you? :-)
>
> Regards,
> Osier
It does, but it's a different story. You should have tried two more commands
after the last one:
# virsh net-start default
# ps -ef | grep dnsmasq
then, you would have found the grepping positive. That's what I'am actually
talking about :)
<...>
Thanks for the response, but my question was whether it's possible to start
libvirtd (and hence, activate the virtual networks "automatically") on
boot, but
without dnsmasq being started along the way.
</...>
As far as I understand from this, you just want the network not started
along with libvirtd. Why do you want to start it again by "net-start"
when it's already not started along with libvirtd? :-)
Osier
3:04 a.m.
On Thu, Sep 13, 2012 at 03:54:30PM +0800, Osier Yang wrote:
On 2012年09月13日 15:50, Marwan Tanager wrote:
>On Thu, Sep 13, 2012 at 03:17:14PM +0800, Osier Yang wrote:
>>On 2012年09月13日 14:55, Marwan Tanager wrote:
>>>On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
>>>>On 2012年09月13日 11:23, Marwan Tanager wrote:
>>>>
>>>>No, to disable the autostarting of dnsmasq, you need to disable the
>>>>autostart of network which drives dnsmasq (named 'default' by
default).
>>>>
>>>>% virsh net-autostart --disable default
>>>>
>>>>Then it won't be started automatically along with libvirtd service
next
>>>>time.
>>>
>>>Thanks for the response, but my question was whether it's possible to
start
>>>libvirtd (and hence, activate the virtual networks "automatically")
on boot, but
>>>without dnsmasq being started along the way. Your answer means that to
disable
>>>dnsmasq from starting automatically, I need to disable the network form
starting
>>>automatically too.
>>>
>>>Anyway, I destroyed the 'default' network, then killed the dnsmasq
process for
>>>that network, but when I started it again, dnsmasq started along with it. So,
it
>>>appears that the whole thing is hard coded.
>>
>>No, it depends on your previous network status, note that libvirt
>>saves the object's state, so that things could be consistent before
>>restarting/reloading.
>>
>># virsh net-list --all
>>Name State Autostart
>>-----------------------------------------
>>default active no
>>
>># service libvirtd restart
>>Restarting libvirtd (via systemctl): [ OK ]
>>
>># virsh net-list --all
>>Name State Autostart
>>-----------------------------------------
>>default active no
>>
>># pidof libvirtd
>>6868
>># pidof dnsmasq
>>6826
>>
>>
>># virsh net-destroy default
>>Network default destroyed
>>
>># service libvirtd restart
>>Restarting libvirtd (via systemctl): [ OK ]
>>
>># virsh net-list --all
>>Name State Autostart
>>-----------------------------------------
>>default inactive no
>>
>># ps -ef | grep dnsmasq
>>root 6762 20112 0 15:07 pts/1 00:00:00 grep --color=auto dnsmasq
>># pidof libvirtd
>>6689
>>
>>Does this make sense to you? :-)
>>
>>Regards,
>>Osier
>
>It does, but it's a different story. You should have tried two more commands
>after the last one:
>
># virsh net-start default
># ps -ef | grep dnsmasq
>
>then, you would have found the grepping positive. That's what I'am actually
>talking about :)
>
<...>
Thanks for the response, but my question was whether it's possible to start
libvirtd (and hence, activate the virtual networks "automatically")
on boot, but
without dnsmasq being started along the way.
</...>
As far as I understand from this, you just want the network not started
along with libvirtd. Why do you want to start it again by "net-start"
when it's already not started along with libvirtd? :-)
I want the network to start automatically with libvirtd but "without" dnsmasq. I
haven't say anything about starting it with net-start. I've just put those two
commands to show you that merely starting the netwrok "causes" dnsmasq to start
too, hence I had talked about the thing being hardcoded.
Marwan
3:14 a.m.
On 2012年09月13日 16:04, Marwan Tanager wrote:
On Thu, Sep 13, 2012 at 03:54:30PM +0800, Osier Yang wrote:
> On 2012年09月13日 15:50, Marwan Tanager wrote:
>> On Thu, Sep 13, 2012 at 03:17:14PM +0800, Osier Yang wrote:
>>> On 2012年09月13日 14:55, Marwan Tanager wrote:
>>>> On Thu, Sep 13, 2012 at 01:04:58PM +0800, Osier Yang wrote:
>>>>> On 2012年09月13日 11:23, Marwan Tanager wrote:
>>>>>
>>>>> No, to disable the autostarting of dnsmasq, you need to disable the
>>>>> autostart of network which drives dnsmasq (named 'default' by
default).
>>>>>
>>>>> % virsh net-autostart --disable default
>>>>>
>>>>> Then it won't be started automatically along with libvirtd
service next
>>>>> time.
>>>>
>>>> Thanks for the response, but my question was whether it's possible to
start
>>>> libvirtd (and hence, activate the virtual networks
"automatically") on boot, but
>>>> without dnsmasq being started along the way. Your answer means that to
disable
>>>> dnsmasq from starting automatically, I need to disable the network form
starting
>>>> automatically too.
>>>>
>>>> Anyway, I destroyed the 'default' network, then killed the
dnsmasq process for
>>>> that network, but when I started it again, dnsmasq started along with it.
So, it
>>>> appears that the whole thing is hard coded.
>>>
>>> No, it depends on your previous network status, note that libvirt
>>> saves the object's state, so that things could be consistent before
>>> restarting/reloading.
>>>
>>> # virsh net-list --all
>>> Name State Autostart
>>> -----------------------------------------
>>> default active no
>>>
>>> # service libvirtd restart
>>> Restarting libvirtd (via systemctl): [ OK ]
>>>
>>> # virsh net-list --all
>>> Name State Autostart
>>> -----------------------------------------
>>> default active no
>>>
>>> # pidof libvirtd
>>> 6868
>>> # pidof dnsmasq
>>> 6826
>>>
>>>
>>> # virsh net-destroy default
>>> Network default destroyed
>>>
>>> # service libvirtd restart
>>> Restarting libvirtd (via systemctl): [ OK ]
>>>
>>> # virsh net-list --all
>>> Name State Autostart
>>> -----------------------------------------
>>> default inactive no
>>>
>>> # ps -ef | grep dnsmasq
>>> root 6762 20112 0 15:07 pts/1 00:00:00 grep --color=auto dnsmasq
>>> # pidof libvirtd
>>> 6689
>>>
>>> Does this make sense to you? :-)
>>>
>>> Regards,
>>> Osier
>>
>> It does, but it's a different story. You should have tried two more commands
>> after the last one:
>>
>> # virsh net-start default
>> # ps -ef | grep dnsmasq
>>
>> then, you would have found the grepping positive. That's what I'am
actually
>> talking about :)
>>
>
> <...>
> Thanks for the response, but my question was whether it's possible to start
> libvirtd (and hence, activate the virtual networks "automatically")
> on boot, but
> without dnsmasq being started along the way.
> </...>
>
> As far as I understand from this, you just want the network not started
> along with libvirtd. Why do you want to start it again by "net-start"
> when it's already not started along with libvirtd? :-)
I want the network to start automatically with libvirtd but "without" dnsmasq.
I
haven't say anything about starting it with net-start. I've just put those two
commands to show you that merely starting the netwrok "causes" dnsmasq to
start
too, hence I had talked about the thing being hardcoded.
Okay, finally I understood, that's because the default network use
"nat" forward mode, and dnsmasq is the only one supported DHCP
server libvirt supports for DHCPv4.
If you want to use the default NAT network, but to use your own
DHCP server instead of dnsmasq, patches/RFC/ideas are welcomed
(libvir-list(a)redhat.com).
If you want to use network in mode other than NAT. You won't have
to suffer from the dnsmasq. For the network XML format:
http://libvirt.org/formatnetwork.html
Regards,
Osier
4:26 a.m.
On Thu, Sep 13, 2012 at 04:14:30PM +0800, Osier Yang wrote:
Okay, finally I understood, that's because the default network use
"nat" forward mode, and dnsmasq is the only one supported DHCP
server libvirt supports for DHCPv4.
If you want to use the default NAT network, but to use your own
DHCP server instead of dnsmasq, patches/RFC/ideas are welcomed
(libvir-list(a)redhat.com).
If you want to use network in mode other than NAT. You won't have
to suffer from the dnsmasq. For the network XML format:
http://libvirt.org/formatnetwork.html
Well, the only solution then, for PXE to work properly is to use the 'bootp'
element in the network xml file. I've just tried it after deleting the virtual
interfaces configurations in my local DHCP server and it worked perfectly.
Thanks Osier for the pointers.
Marwan
3:42 p.m.
On 09/13/2012 04:14 AM, Osier Yang wrote:
If you want to use the default NAT network, but to use your own
DHCP server instead of dnsmasq, patches/RFC/ideas are welcomed
(libvir-list(a)redhat.com).
If you want to use network in mode other than NAT. You won't have
to suffer from the dnsmasq. For the network XML format:
That's not exactly correct. Any network defined with <forward
mode='nat'>, <forward mode='route'>, or no forward element at
all, will
result in libvirtd creating a new bridge device for that network. If the
network also has an IP address defined, then a dnsmasq instance will be
started, listening *only* on that IP address (i.e. only on the bridge)
for DNS requests. If the <ip> element also has a <dhcp> section, then
the dnsmasq instance will also listen on the dhcp port *only* on the bridge.
For <forward mode='bridge'> and <forward mode='hostdev'>, no
bridge
device is created by libvirt, no IP address is configured on the host,
and no dnsmasq is started.
4453
days inactive
4453
days old
9 comments
3 participants
participants (3)
-
Laine Stump -
Marwan Tanager -
Osier Yang