<div dir="ltr">Hello, Alvise<div><br></div><div>It is possible that the version of dnsmasq and lease time is an issue:</div><div><br></div><div><a href="https://bugs.launchpad.net/nova/+bug/887162">https://bugs.launchpad.net/nova/+bug/887162</a><br>

</div><div><br></div><div><a href="http://markmail.org/message/7kjf4hljszpydsrx#query:+page:1+mid:7kjf4hljszpydsrx+state:results">http://markmail.org/message/7kjf4hljszpydsrx#query:+page:1+mid:7kjf4hljszpydsrx+state:results</a><br>

</div><div><br></div><div>Hope this helps.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div><div>Mirantis Inc.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Aug 14, 2013 at 4:19 PM, Alvise Dorigo <span dir="ltr"><<a href="mailto:alvise.dorigo@pd.infn.it" target="_blank">alvise.dorigo@pd.infn.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Dear list,<br>
I'm facing a problem related with network bring up inside a virtual instance Scientific Linux 5.<br>
My Openstack installation has been made with packstack (with options --allinone --os-swift-install=n --os-quantum-install=n --os-cinder-install=n), using the latest Grizzly, on a Scientific Linux 6.4 host machine:<br>
<br>
[root@lxadorigo log]# rpm -qa|egrep 'openstack|qemu|virt|dnsmasq'<br>
<br>
qemu-img-0.12.1.2-2.355.el6_4.6.x86_64<br>
openstack-packstack-2013.1.1-0.24.dev660.el6.noarch<br>
dnsmasq-utils-2.48-13.el6.x86_64<br>
libvirt-client-0.10.2-18.el6_4.9.x86_64<br>
libvirt-python-0.10.2-18.el6_4.9.x86_64<br>
openstack-nova-scheduler-2013.1.3-1.el6.noarch<br>
openstack-glance-2013.1.2-2.el6.noarch<br>
openstack-nova-common-2013.1.3-1.el6.noarch<br>
openstack-nova-network-2013.1.3-1.el6.noarch<br>
gpxe-roms-qemu-0.9.7-6.9.el6.noarch<br>
libvirt-0.10.2-18.el6_4.9.x86_64<br>
openstack-nova-compute-2013.1.3-1.el6.noarch<br>
openstack-utils-2013.1-8.el6.noarch<br>
python-django-openstack-auth-1.0.7-1.el6.noarch<br>
openstack-nova-api-2013.1.3-1.el6.noarch<br>
qemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64<br>
openstack-nova-conductor-2013.1.3-1.el6.noarch<br>
openstack-nova-cert-2013.1.3-1.el6.noarch<br>
kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64<br>
virt-what-1.11-1.2.el6.x86_64<br>
openstack-nova-novncproxy-2013.1.3-1.el6.noarch<br>
openstack-dashboard-2013.1.1-1.el6.noarch<br>
kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch<br>
openstack-keystone-2013.1.3-1.el6.noarch<br>
openstack-nova-console-2013.1.3-1.el6.noarch<br>
dnsmasq-2.48-13.el6.x86_64<br>
<br>
[root@lxadorigo log]# uname -r<br>
2.6.32-358.114.1.openstack.el6.gre.2.x86_64<br>
<br>
<br>
When I upload a Scientific Linux 6 AMI image (linked to a proper kernel and initramfs) and then I start it, I do not have any problem with it; the instance starts and this is the response the dhcp client gets from the dnsmasq:<br>


<br>
Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read /etc/hosts - 2 addresses<br>
Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read /var/lib/nova/networks/nova-br100.conf<br>
Aug 14 13:48:45 lxadorigo kernel: kvm: 24134: cpu0 disabled perfctr wrmsr: 0xc1 data 0xabcd<br>
Aug 14 13:48:51 lxadorigo kernel: device vnet0 entered promiscuous mode<br>
Aug 14 13:48:51 lxadorigo kernel: br100: port 1(vnet0) entering forwarding state<br>
Aug 14 13:48:51 lxadorigo qemu-kvm: Could not find keytab file: /etc/qemu/krb5.tab: No such file or directory<br>
Aug 14 13:48:54 lxadorigo ntpd[2283]: Listening on interface #15 vnet0, fe80::fc16:3eff:fe16:fbbc#123 Enabled<br>
Aug 14 13:48:56 lxadorigo kernel: kvm: 24392: cpu0 unhandled wrmsr: 0x391 data 2000000f<br>
Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPDISCOVER(br100) fa:16:3e:16:fb:bc<br>
Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPOFFER(br100) 192.168.32.4 fa:16:3e:16:fb:bc<br>
Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPREQUEST(br100) 192.168.32.4 fa:16:3e:16:fb:bc<br>
Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPACK(br100) 192.168.32.4 fa:16:3e:16:fb:bc sl64-5gb<br>
<br>
<br>
<br>
If I upload a Scientific Linux 5, when its dhclient asks the dnsmasq for negotiation this is the dnsmasq's answer:<br>
<br>
Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read /etc/hosts - 2 addresses<br>
Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read /var/lib/nova/networks/nova-br100.conf<br>
Aug 14 14:08:55 lxadorigo kernel: kvm: 26374: cpu0 disabled perfctr wrmsr: 0xc1 data 0xabcd<br>
Aug 14 14:09:00 lxadorigo kernel: device vnet0 entered promiscuous mode<br>
Aug 14 14:09:00 lxadorigo kernel: br100: port 1(vnet0) entering forwarding state<br>
Aug 14 14:09:00 lxadorigo qemu-kvm: Could not find keytab file: /etc/qemu/krb5.tab: No such file or directory<br>
Aug 14 14:09:03 lxadorigo ntpd[2283]: Listening on interface #18 vnet0, fe80::fc16:3eff:fea4:1cb8#123 Enabled<br>
Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100) fa:16:3e:a4:1c:b8<br>
Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100) 192.168.32.2 fa:16:3e:a4:1c:b8<br>
<br>
without any DHCPOFFERS message. Now, I'm not a network and/or dnsmasq expert but this behavior is quite strange; in addition the two images (SL5 and SL6) has been made with exactly the same procedure.<br>
<br>
Do you have any advice about what/where I could investigate to solve this problem ?<br>
<br>
thanks in advance,<br>
<br>
        Alvise<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>