Red Hat Bugzilla – Bug 454616
libvirt returns wrong console tty with xenner
Last modified: 2008-10-17 06:02:34 EDT
Description of problem: see $summary Version-Release number of selected component (if applicable): libvirt-0.4.4-1.fc8 How reproducible: boot a xen guest with xenner Actual results: zweiblum root ~# virsh ttyconsole testinstall /dev/pts/7 Expected results: zweiblum root ~# virsh ttyconsole testinstall /dev/pts/8 Additional info: zweiblum root ~# grep redir /var/log/libvirt/qemu/testinstall.log char device redirected to /dev/pts/7 char device redirected to /dev/pts/8 first is monitor, second is console (aka serial line).
Created attachment 311366 [details] complete logfile.
Here's the problem in qemu_driver.c: static int qemudWaitForMonitor(virConnectPtr conn, struct qemud_driver *driver, struct qemud_vm *vm) { char buf[1024]; /* Plenty of space to get startup greeting */ int ret = qemudReadMonitorOutput(conn, driver, vm, vm->stderr, buf, sizeof(buf), qemudFindCharDevicePTYs, "console"); 1024 bytes is plenty for regular QEMU, but as can be seen from the attachment in comment #1, it is no where near enough for it to work with xenner.
Created attachment 311382 [details] Fix parsing of stdout to fetch TTYs When parsing for multiple TTYs, the code wasn't correctly taking account of possibility of having leading lines of garbage before the TTY output. So it was not skipping forward enough after finding the first TTY, and thus getting the same TTY twice, and/or other serious confusion. This patch fixes this problem. So attempting to start xenner now results in # virsh start xenner libvir: QEMU error : internal error Out of space while reading console startup output error: Failed to start domain xenner which is what I would expect since Xenner's output is longer than 1024 bytes.
Ok, can we also enlarge the buffer please? Alternatively find another way for xenner's debug logging than writing to stderr.
*** Bug 459791 has been marked as a duplicate of this bug. ***
Was there a found solution for this bug ? I applied the patch with no hope. Any procedures to avoid this occurring will be appreciated.
Hello, It turns out that the Xenner services was not running by default in Fedora 9, applying /etc/init.d/xenner to start on booting fixed this issues so far besides applying the patch https://bugzilla.redhat.com/attachment.cgi?id=311382 . Thanks, /Ahmed Medhat/
*** Bug 462120 has been marked as a duplicate of this bug. ***
Should be fixed with libvirt 0.4.6 and xenner 0.46, which are both in fedora9 updates now.
Created attachment 320610 [details] Screenshot showing where the rawhide installation stops [root@snowball jsikorski]# rpm -q libvirt libvirt-0.4.6-2.fc9.x86_64 [root@snowball jsikorski]# rpm -q xenner xenner-0.46-1.fc9.x86_64 [root@snowball jsikorski]# Not sure if the problem is really fixed. I have attempted to install rawhide today, using the following command: virt-install --paravirt --os-type=linux --location=http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/development/i386/os/ --name=pararawhide-i386 --vcpus=1 --file=/var/lib/libvirt/images/pararawhide-i386.img --accelerate --ram=512 --file-size=15 Unfortunately, all I got is this (see attachment). And yes, xenner should be running by default, or at least something should start it up.
Not related at all, open a new bug please.