Bug 915468

Anyone has any idea about this problem?   Thanks! 

OS I am running is -- 
root>  uname -r
2.6.32-358.0.1.el6.x86_64

And the libvirt I have is --
root>  rpm -qa | grep libvirt
libvirt-client-0.10.2-18.el6.x86_64
libvirt-python-0.10.2-18.el6.x86_64
libvirt-0.10.2-18.el6.x86_64
libvirt-client-0.10.2-18.el6.i686

Please attach the libvirtd logs to the BZ.

BTW, what's your libvirt version before apply update?

I'm trying to reproduce your problem, after update libvirt, libvirtd still running:
libvirt-0.10.0-1.el6 -->libvirt-0.10.2-18.el6

You can discard this request now, we have found a work around.   Just for your information here is what we found: 

First to answer your question -- I had libvirt-0.9.10 before. 

In my virtual machine configuration file <machine>.xml under /etc/libvirt/qemu/ there are some cpu features configuration that the old version put there when I originally created this vm,  and the new libvirt 0.10.2 does not like them.  

The work around was either remove those cpu features (pasted below) from the file or recreate the virtual machine (which resulted in a new file without those features).  We were able to use these work around and get over the problem.  

<!--
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='lahf_lm'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='cx16'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='acpi'/>
  -->


Thanks, 
zbao

Yanbing, I'd be quite surprised if changing the guest XML made a difference, but can you reproduce what the reporter is describing?

Interesting. Could attach the original domain XML and debug logs from libvirtd (see http://wiki.libvirt.org/page/DebugLogs) generated while the host is booting and libvirtd fails to start?

(In reply to comment #6)
> Yanbing, I'd be quite surprised if changing the guest XML made a difference,
> but can you reproduce what the reporter is describing?

Yes, no difference, after doing the XML change and update libvirt from libvirt-0.9.10-21.el6 to libvirt-0.10.2-18.el6, libvirtd still running.

zbao,

even if we had a bug in our XML parsing part, that should not prevent the daemon from starting up. Can you please provide debug logs as requested in comment #8?

Created attachment 708391 [details]
one of the log files I got earlier

Hi,  

As you requested I am attaching one of the libvirt log I got earlier when the problem was still happening. Hope it helps. 

As you mentioned that you could not reproduce the problem on your side, so I went ahead added those <feature policy> lines into my xml file, and rebooted the box and everything still worked!   

It is bizarre,  looks like I won't be able to recreate the problem either.  

Thanks, 

zbao

From the debug logs I see libvirtd died due to SIGSEGV. So if you ever hit the problem - the core dump would be fine. Unfortunately, logs does not tell us where the NULL deref happened exactly. However it seems like you have an autostarted domain configured. So libvirt tries to start it up while doing its own initialization. So it might have accessed an yet uninitialized value, but this is just a rough guess.

Glad you mentioned 'autostart',  yes on my host originally I had that option set, so was on my co-workers' host.  When he ran into the same problem on hist host,  he first unchecked that option,  and libvirtd did start fine, but his vm still had problem, so he then did some investigation and commented those policy features in his .xml file and everything started to work.   So I think your rough guess might be very close to what happened on hist host.  Next time if something like this happens I will try to get a core dump for you guys.  

Anyway,  everything is working for us now, if you guys want to close this request please go ahead.  And thanks for looking into this! 

zbao

We run coverity checks over libvirt periodically. So it is possible that this issue has been fixed already. Moreover, from comment 13 it looks like it is fixed. Therefore, I am closing this as UPSTREAM. If somebody thinks otherwise, please feel free to re-open.