Hello.
We finally found the cause of this problem.
When we use virsh reboot domain, it is actually two calls
qemuMonitorSystemPowerdown() and qemuProcessFakeReboot().
Inside the first call domain stateReason is set to
VIR_DOMAIN_SHUTDOWN_UNKNOWN and then virDomainSaveStatus() is called.
Inside
Hello.
We notice a very upsetting behavior of how libvirtd deals with running domains
after being restarted.
Namely, in 10-20s after start libvirtd may accidentally kill a random number of
running (qemu) domains with SIGTERM.
Here is what we get in libvirt log:
2013-02-27 12:35:10.415+:
On 03/02/2013 04:35 AM, Igor Lukyanov wrote:
Hello.
We notice a very upsetting behavior of how libvirtd deals with running domains
after being restarted.
Namely, in 10-20s after start libvirtd may accidentally kill a random number of
running (qemu) domains with SIGTERM.
[...]
Specifically
On 03/02/2013 09:39 AM, Andrey Korolyov wrote:
Sorry in advance for possible top-post, I`m not able to add proper
messageid here.
Does it ever occur if you don't run with DHCP snooping enabled?
Stefan
No, please disregard those errors. We don`t run DHCP snooping/IP
learning on interfaces
Sorry in advance for possible top-post, I`m not able to add proper
messageid here.
Does it ever occur if you don't run with DHCP snooping enabled?
Stefan
No, please disregard those errors. We don`t run DHCP snooping/IP
learning on interfaces but only modified clean-traffic rules, current
Stefan,
qemu-1.1.2 with dfsg-5 patchset
http://ftp.de.debian.org/debian/pool/main/q/qemu/qemu_1.1.2+dfsg-5.debian.tar.gz
for example
VM` xml is quite simple, qemu64 cpu model, pc-1.1 machine model, one
virtio disk, two bridged virtio NICs, serial and virtio-serial ptys.
On Sat, Mar 2, 2013 at
