1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
qemu/kvm hangs reading from serial console
This is for a qemu-kvm running on RHEL 5, so it's pretty old,
but i think the problem still exists in 1.2
We have conman running on our hosts, connecting to the
kvm/qemu's using
virsh console
which just opens up the console /dev/pts/slave that qemu
opens up when run with options
-nographic
-serial mon:pty
Sometimes virsh console exits and then qemu locks up.
My guess is that something like this happens:
virsh console exits
qemu does a select() on /dev/ptmx (and other FDs)
select() returns the FD of /dev/ptmx in the read-fdset
qemu does a read()
read() returns -1 (EIO)
qemu does other stuff for a while
select() ... /dev/ptmx
read() .. EIO
other stuff
select() ... read() ... select() ... read() ... select()
conman starts a new virsh console that connects
qemu does a read()
read() blocks b/c there is now a writer on the tty slave
So i don't see any way around this, given the sorta rudi-
mentary semantics of TTY IO on Linux (not that i know of
any platform that does it better ... ?), except ...
maybe qemu should
fcntl(master_fd, F_SETFL, flags | O_NONBLOCK)
in qemu-char.c:qemu_char_open_pty()
and be prepared to handle E_WOULDBLOCK|E_AGAIN in
qemu-char.c:fd_chr_read() ... ?
--buck
[*] i think, b/c in the old version we are running, sometimes
the guest spits out the
^]
character to its console, and virsh console reads it and
doesn't check to see if its from stdin or the pty and exits,
which, i think, can be fixed like this:
--- libvirt-0.8.2/tools/console.c.ctrl_close_bracket_handling_fix 2012-09-06 10:30:43.606997191 -0400
+++ libvirt-0.8.2/tools/console.c 2012-09-06 10:34:52.154000464 -0400
@@ -155,6 +155,7 @@ int vshRunConsole(const char *tty) {
/* Quit if end of file, or we got the Ctrl-] key */
if (!got ||
+ fds[i].fd == STDIN_FILENO &&
(got == 1 &&
buf[0] == CTRL_CLOSE_BRACKET))
goto done;
|