Bug 1036883

Would you copy you vdsm.log, from the long vmCreate line until the
failure? Since "vnet0" is a device created automatically by libvirt,
please include relevant part of libvirtd.log, too.

closing since we cannot proceed without the log. please re-open when you can provide it. thanks.

Hi,

I would like to request the reopen of this bug since I'm having exactly the same problem:

This is the error in vdsm.log:

4b770-9bb6-4c12-8e83-f798174615c8`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 2092, in _startUnderlyingVm
    self._run()
  File "/usr/share/vdsm/vm.py", line 2959, in _run
    self._connection.createXML(domxml, flags),
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 76, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error ifname "vnet0" not in key map
Thread-2200185::DEBUG::2014-02-11 06:51:35,063::vm::2522::vm.Vm::(setDownStatus) vmId=`38d4b770-9bb6-4c12-8e83-f798174615c8`::Changed state to Down: internal error ifname "vnet0" not in key map

We are running the ovirt node on a RHEL 6.4 with the following relevant packages installed:

vdsm-python-cpopen-4.13.0-11.el6.x86_64
libvirt-lock-sanlock-0.10.2-29.el6.1.x86_64
vdsm-4.13.0-11.el6.x86_64
vdsm-xmlrpc-4.13.0-11.el6.noarch
vdsm-cli-4.13.0-11.el6.noarch
libvirt-python-0.10.2-29.el6.1.x86_64
libvirt-0.10.2-29.el6.1.x86_64
libvirt-client-0.10.2-29.el6.1.x86_64
vdsm-python-4.13.0-11.el6.x86_64

Let me know if you need any additional data.

/Xavier

Xavier, please look into comment 1 for additionally requested information (more of vdsm.log and libvirtd.log). Is the problem specific to one Vm? one host? Simply re-open the bug once you provide this data.

Created attachment 861771 [details]
libvidrtd log

Created attachment 861772 [details]
vdsm log

Hi Dan, The problem happens to every VM I create and I only have one host in the setup. I attached the requested logs but I don't see how can I reopen the bug.

Xavier, can you tell of any difference between a "good" host and the "bad" one? Could you share your /etc/libvirtd/libvirtd.conf and /etc/libvirtd/qemu.conf ? Do you have ssl=True in your /etc/vdsm/vdsm.conf?

 2014-02-11 11:22:16.228+0000: 8061: error : qemuBuildGraphicsCommandLine:4899 : unsupported configuration: spice secure channels set in XML configuration, but TLS is disabled in qemu.conf


Laine, do you have a clue how the following error is related to the former one

2014-02-11 11:22:16.336+0000: 8061: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet0" not in key map

?

Dan,

ssl = True in /etc/vdsm/vdsm.conf

(this rings a bell, we had problems once and run this: http://www.ovirt.org/Building_oVirt_engine#Host_Non-Responsive to solve it)

Regarding the hosts, we had a working test installation with ovirt 3.0(?) and we decided to upgrade to 3.3. Since it was only test we decided to just reinstall everything. We have been having this problem since then and we haven't been able to start a VM once in 3.3

Created attachment 861786 [details]
libvirtd log

Created attachment 861787 [details]
/etc/libvirt/qemu.conf

(In reply to Dan Kenigsberg from comment #8)

>  2014-02-11 11:22:16.228+0000: 8061: error :
> qemuBuildGraphicsCommandLine:4899 : unsupported configuration: spice secure
> channels set in XML configuration, but TLS is disabled in qemu.conf
> 
> 
> Laine, do you have a clue how the following error is related to the former
> one
> 
> 2014-02-11 11:22:16.336+0000: 8061: error : virNWFilterDHCPSnoopEnd:2131 :
> internal error ifname "vnet0" not in key map

The first is the real error; the second is an inconsequential result of cleaning up after a guest that didn't totally start.

More detail:

The first error seems pretty straightforward - either you need to disable secure channels for spice, or you need to enable TLS in qemu.conf. Not sure why that is an error now and wasn't in the past - perhaps we were previously ignoring one when the other wasn't set, or something like that - it's not really my area of knowledge.

As for the 2nd error, that isn't really an error - it's just a situation that happens sometimes when a guest is shut down without being totally brought up (so there will be no entry for the guest's interface in nwfilter's snoop table yet, for example when an invalid config such as indicated above has caused the guest to fail during startup). In newer versions of libvirt, that error is completely removed; for RHEL6 it is logged, but has no further effect (since the function generating it returns void).

Thanks, Laine. I have a sense of deja vu regarding your explanation.

Indeed, spice_tls=0 of qemu.conf conflicts with ssl=True. The simplest way to solve this is to stop libvirtd, remove the vdsm-configured parts of qemu.conf and libvirtd.conf, and run

  vdsm-tool configure --force

Yaniv, I believe that the need to manually remove the vdsm-configured bits is the real bug here. configure --force should do that by itself.

Ok so I ran 

vdsm-tool libvirt-configure --force
vdsm-tool libvirt-configure-services-restart

after I manually removed the vdsm-configured parts of qemu.conf and libvirt.conf and now the machines are starting!

The next step is now to figure out why do I get a "Unable to connect to the graphic server (null)" error when trying to open a spice console.

Thank you for the help!

libvirt_configure.sh already manage to set the right configure in libvirtd.conf and qemu.conf according to the ssl verb in vdsm.conf.
BUT, without the attached patch (24132) we validate the current config state before overriding the files even though the --force flag was stated and vdsm-tool fails the configure.
With that patch, setting in vdsm.conf ssl=True and then running "vdsm-tool configure --force" will update libvirtd.conf and qemu.conf according to vdsm.conf state.
this omits the validate check while overriding is required during the configure.

the fix is not fully merged to 3.4 yet and not included in ovirt-3.4.0-beta3

vm can be started. if there is a conflict between the qemu.conf and vdsm.conf,vdsm-tool configure --force updates libvirtd.conf and qemu.conf according to vdsm.conf state.
vdsm 4.14.2-0.3
ovirt engine 3.4 - 3.4.0-0.3.master.el6ev

this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released