another issue we(kolla gate) meet is libvirtd got segment fault.
Here is the log from host messages file. But i do not get other issue in
nova.conf expect can not connect libvirt.
Dec 25 13:40:54 localhost kernel: libvirtd[5720]: segfault at 8 ip
00007fa70379b823 sp 00007fa6faa061c0 error 4 in libvirt.so.0.2000.0[
7fa703648000+353000]
On Fri, Dec 23, 2016 at 10:00 PM, Neil Jerram <n...@tigera.io> wrote:
> On Fri, Dec 23, 2016 at 1:37 PM Steve Gordon <sgor...@redhat.com> wrote:
>
>> ----- Original Message -----
>> > From: "Neil Jerram" <n...@tigera.io>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> >
>> > I appreciate that even libvirt 2.0.0 will be ancient history by now, to
>> its
>> > developers, but I am seeing further issues that look associated with the
>> > recent CentOS 7 transition from libvirt 1.2.7 to libvirt 2.0.0, and
>> would
>> > appreciate any comments on them that people may have. I believe these
>> > issues are independent of those that have already been discussed on
>> other
>> > threads.
>> >
>> > First, this traceback in nova-compute.log:
>> >
>> > Traceback (most recent call last):
>> > File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> > 2156, in _build_resources
>> > yield resources
>> > File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> > 2009, in _build_and_run_instance
>> > block_device_info=block_device_info)
>> > File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 2534, in spawn
>> > block_device_info=block_device_info)
>> > File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 4620, in _create_domain_and_network
>> > xml, pause=pause, power_on=power_on)
>> > File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 4550, in _create_domain
>> > guest.launch(pause=pause)
>> > File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
>> line
>> > 142, in launch
>> > self._encoded_xml, errors='ignore')
>> > File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
>> 195,
>> > in __exit__
>> > six.reraise(self.type_, self.value, self.tb)
>> > File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
>> line
>> > 137, in launch
>> > return self._domain.createWithFlags(flags)
>> > File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186,
>> in
>> > doit
>> > result = proxy_call(self._autowrap, f, *args, **kwargs)
>> > File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144,
>> in
>> > proxy_call
>> > rv = execute(f, *args, **kwargs)
>> > File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125,
>> in
>> > execute
>> > six.reraise(c, e, tb)
>> > File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83,
>> in
>> > tworker
>> > rv = meth(*args, **kwargs)
>> > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1065, in
>> > createWithFlags
>> > if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
>> failed',
>> > dom=self)
>> > libvirtError: Cannot find '' in path: No such file or directory
>> >
>> > which I believe is caused by the empty path attribute in this part of
>> the
>> > XML:
>> >
>> > <interface type='ethernet'>
>> > <mac address='fa:16:3e:3c:96:33'/>
>> > <script path=''/>
>> > <target dev='tap06992dfb-5d'/>
>> > <model type='virtio'/>
>> > <driver name='qemu'/>
>> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> > function='0x0'/>
>> > </interface>
>> >
>> > which is in turn caused, I think, by
>> > https://github.com/openstack/nova/blob/master/nova/virt/
>> libvirt/designer.py#L61
>> >
>> > Is it plausible that libvirt 1.2.7 would have avoided trying to invoke a
>> > script with an empty path, whereas libvirt 2.0.0 does not?
>>
>> It seems someone filed this as https://bugs.launchpad.net/
>> nova/+bug/1649527 from a Nova POV. The Libvirt folks helped me narrow
>> this down to this commit being the first one that would have exhibited this
>> behavior:
>>
>> https://libvirt.org/git/?p=libvirt.git;a=commit;h=
>> 9c17d665fdc5f0ab74500a14c30627014c11b2c0
>>
>> Michal Privoznik provided some additional context:
>>
>> "Previously, libvirt merely just appended 'script=' onto qemu cmd line
>> according to what <script path=''/> contained letting qemu execute the
>> script. That was flawed from security POV (we don't want qemu to be
>> allowed to execute anything) thus libvirt is executing the script now.
>> However, we obviously forgot about this corner case."
>>
>> This actually apparently first appeared in v1.3.3-rc1~71, so it's not new
>> in Libvirt 2.0.0 *but*:
>>
>> * The Ubuntu-based gate is apparently running v1.3.1 at the moment.
>> * The RHEL 7.2 and aligned CentOS included v1.2.17.
>>
>> This is at least partially why this was not seen until recently,
>
>
> Thanks for pinning all of that down!
>
>
>> but it also seems like it might be specific to certain guest networking
>> setup.
>
>
> Yes, there are only a few networking backends that use <interface
> type=ethernet>, I believe; mine is networking-calico, which uses
> VIF_TYPE_TAP; I think (from code reading) that the others are 'ivs',
> 'iovisor', 'midonet' and 'vrouter'. (Although another thing to keep in
> mind here is that os-vif should soon be taking over this area of code - so
> any fixes in nova/virt/libvirt may also be needed in os-vif.)
>
>
> You mentioned you have multiple interfaces attached to the guest, which
>> VIF types and associated Neutron plugins are you using?
>>
>
> Note that the multiple interfaces issue is an additional one. The empty
> path issue causes all VIF_TYPE_TAP tests to fail, whether with just a
> single VM interface, or multiple VM interfaces. I fixed most of those by
> patching my Nova locally (as in https://review.openstack.org/#/c/411936),
> but am still seeing failures in tests with multiple interfaces, which I
> haven't yet investigated further.
>
> Regards,
> Neil
>
>
>
>> Thanks,
>>
>> Steve
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
