----- Original Message -----
> From: "Neil Jerram" <n...@tigera.io>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@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 <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>
> > > 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@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@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
__________________________________________________________________________
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
