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.
Insid
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
is
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 7:
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 bu
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 her
Seems that we have following execution flow:
1. Something calls function
static void qemuMonitorIO(int watch, int fd, int events, void *opaque)
which has following piece of code:
qemu_monitor.c:
599 if (!error &&
600 events & VIR_EVENT_HANDLE_HANGUP) {
601 virR
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+: 45