socket: 0.171
KVM: 0.159
semantic: 0.130
other: 0.122
device: 0.093
performance: 0.055
debug: 0.053
vnc: 0.038
PID: 0.036
graphic: 0.034
permissions: 0.033
network: 0.031
files: 0.027
boot: 0.019
debug: 0.420
KVM: 0.362
network: 0.043
other: 0.036
socket: 0.036
files: 0.021
performance: 0.017
PID: 0.016
semantic: 0.012
device: 0.012
boot: 0.008
graphic: 0.006
permissions: 0.006
vnc: 0.005

not receiving RESET event after system_reset command causes QMP connection to die

I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection:

1) Connect to QMP 
2) Sent qmp_capabilities
3) Receive reply
4) Send system_reset
5) Receive reply
6) close socket
7) Connect to socket -> connection refused

However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events:
1) Connect to QMP 
2) Sent qmp_capabilities
3) Receive reply
4) Send system_reset
5) Receive reply
6) Receive reply (is a RESET event)
7) Receive reply (is a RESET event)
8) close socket
9) Connect to socket -> ok

I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU?

For what its worth, i'm using Ubuntu 12.10:
kvm --version
QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard


Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present.

[Expired for QEMU because there has been no activity for 60 days.]