[openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)

Neil Jerram neil at tigera.io
Fri Dec 16 11:52:21 UTC 2016


Another thought/query about this: is the libvirt transition from 1.2.7 to
2.0.0 less than usually conservative for an RHEL/CentOS series, and if so,
is there a wider reason or move there that it would help to be aware of?
Also is there a way of continuing to use CentOS 7 as a platform but still
using libvirt 1.2.7?

Thanks - Neil


On Fri, Dec 16, 2016 at 11:40 AM Neil Jerram <neil at tigera.io> wrote:

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?

Secondly - if I move past the problem above by changing
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L61
to say 'conf.script = None' - I then find:
- no apparent error in nova-compute.log
- but my instances don't boot
- the following messages in the libvirt log:

Domain id=4 is tainted: high-privileges
char device redirected to /dev/pts/1 (label charserial1)
CPU feature tsc_adjust not found

I guess it's the last message that is the critical one here - can anyone
tell me more about it?

Thanks,
      Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161216/bcbca725/attachment.html>


More information about the OpenStack-dev mailing list