I have a test domain with
<serial type='pty'>
<target port='1'/>
</serial>
and kvm properly starts it with -monitor pty and -serial pty. When
I run 'virsh console' on it, virsh just hangs and cannot be
stopped/interrupted with any of ctrl-c/z/\. SIGTERM works. Strace is
attached (search for "HANGS HERE").
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libvirt-bin depends on:
ii adduser 3.110 add and remove users and groups
ii libavahi-client3 0.6.23-2 Avahi client library
ii libavahi-common3 0.6.23-2 Avahi common library
ii libc6 2.7-16 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-4 simple interprocess messaging syst
ii libgcrypt11 1.4.1-2 LGPL Crypto library - runtime libr
ii libgnutls26 2.4.2-3 the GNU TLS library - runtime libr
ii libgpg-error0 1.4-2 library for common error values an
ii libpolkit-dbus2 0.9-1 library for accessing PolicyKit vi
ii libpolkit2 0.9-1 library for accessing PolicyKit
ii libreadline5 5.2-3 GNU readline and history libraries
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra
ii libselinux1 2.0.65-5 SELinux shared libraries
ii libtasn1-3 1.5-1 Manage ASN.1 structures (runtime)
ii libvirt0 0.5.0-1 library for interfacing with diffe
ii libxenstore3.0 3.2.1-2 Xenstore communications library fo
ii libxml2 2.6.32.dfsg-5 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages libvirt-bin recommends:
ii bridge-utils 1.4-5 Utilities for configuring the Linu
pn dnsmasq <none> (no description available)
ii iptables 1.4.1.1-4 administration tools for packet fi
ii netcat-openbsd 1.89-3 TCP/IP swiss army knife
pn qemu <none> (no description available)
Versions of packages libvirt-bin suggests:
pn policykit <none> (no description available)
-- no debconf information
--
.''`. martin f. krafft <mad...@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
On Wed, Dec 03, 2008 at 12:35:06PM +0100, martin f krafft wrote:
> Package: libvirt-bin
> Version: 0.5.0-1
> Severity: normal
> File: /usr/bin/virsh
>
> I have a test domain with
>
> <serial type='pty'>
> <target port='1'/>
> </serial>
>
> and kvm properly starts it with -monitor pty and -serial pty. When
> I run 'virsh console' on it, virsh just hangs and cannot be
> stopped/interrupted with any of ctrl-c/z/\. SIGTERM works. Strace is
> attached (search for "HANGS HERE").
You can't terminate this with "ctrl-alt-]"? Works here. Can you make
sure your system really *has* output on the serial console by looking
at the /dev/pts/X yourself? You can find out the pty by looking at
/var/log/libvirt/qemu/<yourvm>.log - it should be the last second pty
listed. The first one is the monitor pty.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
How do you suggest that I look at the /dev/pts/X for output?
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"not the truth in whose possession any man is, or thinks he is, but
the honest effort he has made to find out the truth, is what
constitutes the worth of man."
-- gotthold lessing
No, ctrl-alt-] does not terminate the console.
> Works here. Can you make sure your system really *has* output on
> the serial console by looking at the /dev/pts/X yourself? You can
> find out the pty by looking at /var/log/libvirt/qemu/<yourvm>.log
> - it should be the last second pty listed. The first one is the
> monitor pty.
I can use minicom like this:
minicom -op /dev/pts/3
to connect to the monitor just fine, but connecting to /dev/pts/4
doesn't do anything. There seems to be no output, and minicom does
not accept any input from me either. Yet, the guest is running.
Here is the log file:
khyber:/var/log/libvirt/qemu# cat test1.log
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ /usr/bin/kvm -S -M pc -m 256 -smp 3 -name test1 -uuid efdc9c86-5bfd-37fb-b878-da615cdd2235 -monitor pty -boot c -drive file=/dev/mapper/khyber-test1,if=virtio,index=0,boot=on -net nic,macaddr=00:55:50:af:00:01,vlan=0,model=virtio -net tap,fd=10,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:4
char device redirected to /dev/pts/3
char device redirected to /dev/pts/4
info cpus
* CPU #0: pc=0x00000000fffffff0 thread_id=5285
CPU #1: pc=0x00000000fffffff0 thread_id=5286
Cheers,
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"a woman is like your shadow;
follow her, she flies;
fly from her, she follows."
-- sébastien-roch-nicolas chamfort
cat /dev/pts/X
Even though virsh console now works locally, doing the same via
qemu+ssh from a remote system exhibits exactly the same behaviour
when I try to connect to it via qemu+ssh.
It seems that virsh tries to open the *local* /dev/pts/*, which is
a little suboptimal. :)
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
never trust an operating system
for which you do not have the source.
-- source unknown
On Thu, Dec 11, 2008 at 08:44:23PM +0100, martin f krafft wrote:
> Even though virsh console now works locally, doing the same via
> qemu+ssh from a remote system exhibits exactly the same behaviour
> when I try to connect to it via qemu+ssh.
>
> It seems that virsh tries to open the *local* /dev/pts/*, which is
> a little suboptimal. :)
"virsh console" is currently strictly local, it simply opens the pty
specified in the XML config. It also assumes you have the permission to
access the device (so while you can manage the vm as non root you might
to be root to read the serial console). Ideally this would be routed to
libvirtd itself for permission checking and remote console forwarding.
Cheers,
-- Guido