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

Steve Gordon sgordon at redhat.com
Fri Dec 16 16:08:00 UTC 2016


----- Original Message -----
> From: "Neil Jerram" <neil at tigera.io>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Friday, December 16, 2016 10:53:02 AM
> Subject: Re: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)
> 
> On Fri, Dec 16, 2016 at 3:35 PM Steve Gordon <sgordon at redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Neil Jerram" <neil at tigera.io>
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev at lists.openstack.org>
> > > Sent: Friday, December 16, 2016 6:40:57 AM
> > > Subject: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0
> >       (CentOS 7.3)
> > >
> > > 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?
> >
> > Hi Neil,
> >
> > The second seems likely to be related to the addition of support for VMX
> > TSC scaling. What version of qemu are you running?
> 
> 
> Thanks for your reply, Steve.  I have these qemu packages installed:
> 
> [root at neil-fv-0-centos-liberty-compute-node01 qemu]# yum list installed |
> grep qemu
> ipxe-roms-qemu.noarch                20160127-5.git6366fa7a.el7
> libvirt-daemon-driver-qemu.x86_64    2.0.0-10.el7_3.2
> @updates
> qemu-img.x86_64                      10:1.5.3-126.el7
> @base
> qemu-kvm.x86_64                      10:1.5.3-126.el7
> @base
> qemu-kvm-common.x86_64               10:1.5.3-126.el7
> @base
> 
> I should probably also mention that I'm using virt_type = qemu, because my
> compute nodes are GCE instances.
> 
> [root at neil-fv-0-centos-liberty-compute-node01 qemu]# cat
> /etc/nova/nova-compute.conf
> [libvirt]
> virt_type = qemu
> 
> If you haven't already I would suggest grabbing qemu-kvm-ev from the CentOS
> > Virt SIG repos:
> >
> >     http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> >
> > You can enable the repository using this release RPM:
> >
> >
> > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/centos-release-qemu-ev-1.0-1.el7.noarch.rpm
> >
> >
> Would you expect that to help with virt_type = qemu (as well as with
> virt_type = kvm, which I assume is the more common setting)?  If so I'll be
> very excited to try this!

For this particular flag issue I am not 100% sure yet as I'm still checking with some of the qemu folks, but I think it would still be worth a try.

Thanks,

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform



More information about the OpenStack-dev mailing list