Open Stack

Hello, Alvise

It is possible that the version of dnsmasq and lease time is an issue:

https://bugs.launchpad.net/nova/+bug/887162

http://markmail.org/message/7kjf4hljszpydsrx#query:+page:1+mid:7kjf4hljszpydsrx+state:results

Hope this helps.

--
Best regards,
Oleg Gelbukh
Mirantis Inc.



On Wed, Aug 14, 2013 at 4:19 PM, Alvise Dorigo <alvise.dorigo at pd.infn.it>wrote:

> Dear list,
> I'm facing a problem related with network bring up inside a virtual
> instance Scientific Linux 5.
> 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:
>
> [root at lxadorigo log]# rpm -qa|egrep 'openstack|qemu|virt|dnsmasq'
>
> qemu-img-0.12.1.2-2.355.el6_4.6.x86_64
> openstack-packstack-2013.1.1-0.24.dev660.el6.noarch
> dnsmasq-utils-2.48-13.el6.x86_64
> libvirt-client-0.10.2-18.el6_4.9.x86_64
> libvirt-python-0.10.2-18.el6_4.9.x86_64
> openstack-nova-scheduler-2013.1.3-1.el6.noarch
> openstack-glance-2013.1.2-2.el6.noarch
> openstack-nova-common-2013.1.3-1.el6.noarch
> openstack-nova-network-2013.1.3-1.el6.noarch
> gpxe-roms-qemu-0.9.7-6.9.el6.noarch
> libvirt-0.10.2-18.el6_4.9.x86_64
> openstack-nova-compute-2013.1.3-1.el6.noarch
> openstack-utils-2013.1-8.el6.noarch
> python-django-openstack-auth-1.0.7-1.el6.noarch
> openstack-nova-api-2013.1.3-1.el6.noarch
> qemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64
> openstack-nova-conductor-2013.1.3-1.el6.noarch
> openstack-nova-cert-2013.1.3-1.el6.noarch
> kernel-2.6.32-358.114.1.openstack.el6.gre.2.x86_64
> virt-what-1.11-1.2.el6.x86_64
> openstack-nova-novncproxy-2013.1.3-1.el6.noarch
> openstack-dashboard-2013.1.1-1.el6.noarch
> kernel-firmware-2.6.32-358.114.1.openstack.el6.gre.2.noarch
> openstack-keystone-2013.1.3-1.el6.noarch
> openstack-nova-console-2013.1.3-1.el6.noarch
> dnsmasq-2.48-13.el6.x86_64
>
> [root at lxadorigo log]# uname -r
> 2.6.32-358.114.1.openstack.el6.gre.2.x86_64
>
>
> 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:
>
> Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read /etc/hosts - 2 addresses
> Aug 14 13:48:43 lxadorigo dnsmasq[3321]: read
> /var/lib/nova/networks/nova-br100.conf
> Aug 14 13:48:45 lxadorigo kernel: kvm: 24134: cpu0 disabled perfctr wrmsr:
> 0xc1 data 0xabcd
> Aug 14 13:48:51 lxadorigo kernel: device vnet0 entered promiscuous mode
> Aug 14 13:48:51 lxadorigo kernel: br100: port 1(vnet0) entering forwarding
> state
> Aug 14 13:48:51 lxadorigo qemu-kvm: Could not find keytab file:
> /etc/qemu/krb5.tab: No such file or directory
> Aug 14 13:48:54 lxadorigo ntpd[2283]: Listening on interface #15 vnet0,
> fe80::fc16:3eff:fe16:fbbc#123 Enabled
> Aug 14 13:48:56 lxadorigo kernel: kvm: 24392: cpu0 unhandled wrmsr: 0x391
> data 2000000f
> Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPDISCOVER(br100)
> fa:16:3e:16:fb:bc
> Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPOFFER(br100)
> 192.168.32.4 fa:16:3e:16:fb:bc
> Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPREQUEST(br100)
> 192.168.32.4 fa:16:3e:16:fb:bc
> Aug 14 13:49:04 lxadorigo dnsmasq-dhcp[3321]: DHCPACK(br100) 192.168.32.4
> fa:16:3e:16:fb:bc sl64-5gb
>
>
>
> If I upload a Scientific Linux 5, when its dhclient asks the dnsmasq for
> negotiation this is the dnsmasq's answer:
>
> Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read /etc/hosts - 2 addresses
> Aug 14 14:08:53 lxadorigo dnsmasq[25019]: read
> /var/lib/nova/networks/nova-br100.conf
> Aug 14 14:08:55 lxadorigo kernel: kvm: 26374: cpu0 disabled perfctr wrmsr:
> 0xc1 data 0xabcd
> Aug 14 14:09:00 lxadorigo kernel: device vnet0 entered promiscuous mode
> Aug 14 14:09:00 lxadorigo kernel: br100: port 1(vnet0) entering forwarding
> state
> Aug 14 14:09:00 lxadorigo qemu-kvm: Could not find keytab file:
> /etc/qemu/krb5.tab: No such file or directory
> Aug 14 14:09:03 lxadorigo ntpd[2283]: Listening on interface #18 vnet0,
> fe80::fc16:3eff:fea4:1cb8#123 Enabled
> Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:12 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:20 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:28 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:35 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:42 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:09:56 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
> Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPDISCOVER(br100)
> fa:16:3e:a4:1c:b8
> Aug 14 14:10:07 lxadorigo dnsmasq-dhcp[25019]: DHCPOFFER(br100)
> 192.168.32.2 fa:16:3e:a4:1c:b8
>
> 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.
>
> Do you have any advice about what/where I could investigate to solve this
> problem ?
>
> thanks in advance,
>
>         Alvise
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130814/755ffcde/attachment.html>