Description of problem: libvirt doesn't monitor running virtual machines after reboot. Version-Release number of selected component (if applicable): 0.7.5 How reproducible: Always Steps to Reproduce: 1. Start a virtual machine. 2. Reboot libvirt. 3. The virtual machine is running, but libvirt think it's not. So we can start accidentally multiple instances of the same virtual machine that use a same disk which can cause data corruption. Actual results: libvirt doesn't monitor running virtual machines after reboot. Expected results: libvirt should monitor running virtual machines after reboot as in 0.7.4. Additional info: Error log entry: "qemuDomainObjPrivateXMLParse:213 : internal error no monitor path"
I can't reproduce this problem myself. Can you do virsh start SOMEGUEST And then attach the files /var/run/libvirt/qemu/SOMEGUEST.xml and the original /etc/libvirt/qemu/SOMEGUEST.xml and /var/log/libvirt/qemu/SOMEGUEST.log
Created attachment 381751 [details] /var/run/libvirt/qemu XML
Created attachment 381752 [details] /etc/libvirt/qemu XML
Created attachment 381753 [details] Log
Asked files are now attached to the bug report.
Well for some inexplicable reason the status XML is getting written without any of the status info, eg immediately after running 'virsh start', this <domstatus state='running' pid='25309'> <domain type='kvm' id='1'> should look like <domstatus state='running' pid='25309'> <monitor path='/var/lib/libvirt/qemu/debian-sid.monitor' type='unix'/> <vcpus> <vcpu pid='25309'/> </vcpus> <domain type='kvm' id='1'> I'm unable to see why yours is missing this data though
The first machine where I had that problem was an amd64 Debian system. I also tried on a second machine with an i386 Debian system and I had the same problem. Perhaps there is something wrong with build options, could you check it here http://git.debian.org/?p=pkg-libvirt/libvirt.git;a=blob;f=debian/rules;h=ee02de23d9221d1f3b7a0526bb2d21a257162af0;hb=HEAD ?
Having encountered this myself and done some experimentation I have narrowed the problem down a bit. This is probably going to sounds crazy, but here's what I've found: - If I restart libvirtd then I can start and stop a domain from virsh as much as I like and it correctly lists the monitor details in the xml. - If I start a domain from virt-manager instead of virsh then the monitor details will not be listed for that domain. - Once I have started a domain from virt-manager then the monitor details are gone for good (until libvirtd is restarted) and it doesn't matter whether virsh or virt-manager is used to start the domain, the monitor details will still be missing. Hope that helps...
In fact I can go further - starting any domain from virt-manager stops monitor details being recorded for all domains from then on.
Created attachment 385137 [details] Fix rebuild of capabilities object This patch ought to fix the problem with missing monitor path in the XML. The key factor here was that once 'virConnectGetCapabilities' has been called, all future VMs would not have their XML written correctly. virt-manager calls this immediately, explaining Tom's last observation.
I confirm the patch fixes the issue.
I can also confirm that this patch fixes the issue.
Fix included in 0.7.6 release