Bug 451709 - starting domain fails with Unable to open monitor path /dev/pts/...
starting domain fails with Unable to open monitor path /dev/pts/...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 451784
  Show dependency treegraph
 
Reported: 2008-06-16 16:02 EDT by Alan Pevec
Modified: 2008-07-01 01:30 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.4.4-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-01 01:30:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from strace from previous comment. (314.71 KB, text/plain)
2008-06-17 06:04 EDT, Chris Lalancette
no flags Details

  None (edit)
Description Alan Pevec 2008-06-16 16:02:40 EDT
Description of problem:
With libvirt-0.4.3-1 from updates-testing virt-install fails with Unable to open
monitor path /dev/pts/3
The same error happens when trying to start an existing domain with virsh start
Reverting to 0.4.2-4 fixes it.

Version-Release number of selected component (if applicable):
libvirt-0.4.3-1.fc9.i386
python-virtinst-0.300.3-6.fc9.noarch

How reproducible:
always

Steps to Reproduce:
1. yum --enablerepo=updates-testing update libvirt
2. git checkout git://git.et.redhat.com/ovirt.git
3. cd ovirt; ./build-all -acd
  
Actual results:
Starting install...
virDomainCreateLinux() failed internal error Unable to open monitor path /dev/pts/3
Domain installation may not have been successful. 

Expected results:
Starting install...
Domain installation still in progress.  You can reconnect to 
the console to complete the installation process.


Additional info:
trace when running virt-install with LIBVIRT_DEBUG=1

Starting install...
DEBUG: libvirt.c: virDomainLookupByUUIDString (conn=0x9ce8ea8,
uuidstr=ee715b9a-be13-5eed-8afa-a5e1de289a7b)
DEBUG: libvirt.c: virDomainLookupByUUID (conn=0x9ce8ea8, uuid=�q[��^������(�{)
DEBUG: libvirt.c: virConnectGetMaxVcpus (conn=0x9ce8ea8, type=kvm)
Retrieving file .treeinfo...                                                   
                       |  380 B     00:00     
Retrieving file vmlinuz...                                                     
                       | 2.0 MB     00:00     
Retrieving file initrd.img...                                                  
                       | 8.9 MB     00:00     
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=developer)
DEBUG: libvirt.c: virConnectListDomains (conn=0x9ce8ea8, ids=0xbf996538, maxids=500)
DEBUG: libvirt.c: virConnectNumOfDefinedDomains (conn=0x9ce8ea8)
DEBUG: libvirt.c: virConnectListDefinedDomains (conn=0x9ce8ea8, names=0x9d18be0,
maxnames=6)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node5)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d6f200)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node4)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d1eed8)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node3)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9cfbd20)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=rhel5)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9cfbd48)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=bundle9)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d13f20)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=ThinCrust)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d13f70)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d6f200, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d1eed8, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9cfbd20, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9cfbd48, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d13f20, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d13f70, flags=0)
DEBUG: libvirt.c: virDomainFree (domain=0x9d13f70)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d13f70 ThinCrust 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d13f70 ThinCrust)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 7)
DEBUG: libvirt.c: virDomainFree (domain=0x9d13f20)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d13f20 bundle9 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d13f20 bundle9)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 6)
DEBUG: libvirt.c: virDomainFree (domain=0x9cfbd48)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9cfbd48 rhel5 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9cfbd48 rhel5)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 5)
DEBUG: libvirt.c: virDomainFree (domain=0x9cfbd20)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9cfbd20 node3 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9cfbd20 node3)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 4)
DEBUG: libvirt.c: virDomainFree (domain=0x9d1eed8)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d1eed8 node4 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d1eed8 node4)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 3)
DEBUG: libvirt.c: virDomainFree (domain=0x9d6f200)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d6f200 node5 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d6f200 node5)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 2)
DEBUG: libvirt.c: virConnectListDomains (conn=0x9ce8ea8, ids=0xbf996538, maxids=500)
DEBUG: libvirt.c: virConnectNumOfDefinedDomains (conn=0x9ce8ea8)
DEBUG: libvirt.c: virConnectListDefinedDomains (conn=0x9ce8ea8, names=0x9d6c318,
maxnames=6)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node5)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d0fb10)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node4)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d13f48)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=node3)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9cfbd20)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=rhel5)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d13f20)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=bundle9)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d13f70)
DEBUG: libvirt.c: virDomainLookupByName (conn=0x9ce8ea8, name=ThinCrust)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9d171a8)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d0fb10, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d13f48, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9cfbd20, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d13f20, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d13f70, flags=0)
DEBUG: libvirt.c: virDomainGetXMLDesc (domain=0x9d171a8, flags=0)
DEBUG: libvirt.c: virDomainFree (domain=0x9d171a8)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d171a8 ThinCrust 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d171a8 ThinCrust)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 7)
DEBUG: libvirt.c: virDomainFree (domain=0x9d13f70)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d13f70 bundle9 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d13f70 bundle9)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 6)
DEBUG: libvirt.c: virDomainFree (domain=0x9d13f20)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d13f20 rhel5 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d13f20 rhel5)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 5)
DEBUG: libvirt.c: virDomainFree (domain=0x9cfbd20)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9cfbd20 node3 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9cfbd20 node3)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 4)
DEBUG: libvirt.c: virDomainFree (domain=0x9d13f48)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d13f48 node4 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d13f48 node4)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 3)
DEBUG: libvirt.c: virDomainFree (domain=0x9d0fb10)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9d0fb10 node5 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9d0fb10 node5)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9ce8ea8 qemu:///system 2)
DEBUG: libvirt.c: virDomainCreateLinux (conn=0x9ce8ea8, xmlDesc=<domain type='kvm'>
  <name>developer</name>
  <currentMemory>786432</currentMemory>
  <memory>786432</memory>
  <uuid>ee715b9a-be13-5eed-8afa-a5e1de289a7b</uuid>
  <os>
    <type arch='i686'>hvm</type>
    <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz.LN-5Vj</kernel>
    <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.jeauhe</initrd>
    <cmdline>ksdevice=eth0 ks=http://192.168.122.1/ovirt/wui-rel-i386.ks
method=http://192.168.122.1/pungi/9/i386/os</cmdline>
  </os>
  <features>
    <apic/><pae/>
  </features>
  <clock offset="utc"/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <vcpu>1</vcpu>
  <devices>
    <console device='pty'/>
    <disk type='file' device='disk'>
      <source file='/var/lib/libvirt/images/developer.img'/>
      <target dev='hda'/>
    </disk>

    <interface type='network'>
      <source network='default'/>
      <mac address='00:16:3e:49:47:4d'/>
    </interface>
    <interface type='network'>
      <source network='dummybridge'/>
      <mac address='00:16:3e:64:ae:82'/>
    </interface>

    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' />
  </devices>
</domain>
, flags=0)
virDomainCreateLinux() failed internal error Unable to open monitor path /dev/pts/3
Comment 1 Daniel Berrange 2008-06-16 16:08:52 EDT
Can you attach the /var/log/libvirt/qemu/developer.log file.

And is SELinux enabled, or not ?

Can you paste the  ARGV for virt-install if you have them too
Comment 2 Alan Pevec 2008-06-16 16:36:03 EDT
virt-install -n developer -r 768 -f /var/lib/libvirt/images/developer.img --vnc
--accelerate -v --os-type=linux --arch=x86_64 -w network:default -w
network:dummybridge -l http://192.168.122.1/pungi/9/x86_64/os -x 'ksdevice=eth0
ks=http://192.168.122.1/ovirt/wui-rel-x86_64.ks' --noacpi --noautoconsole

/var/log/libvirt/qemu/developer.log:
/usr/bin/qemu-kvm -S -M pc -m 768 -smp 1 -name developer -monitor pty -no-reboot
-no-acpi -boot c -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.jRf8yW -initrd
/var/lib/libvirt/boot/virtinst-initrd.img.WpojJt -append ksdevice=eth0
ks=http://192.168.122.1/ovirt/wui-rel-x86_64.ks
method=http://192.168.122.1/pungi/9/x86_64/os -drive
file=/var/lib/libvirt/images/developer.img,if=ide,index=0,boot=on -net
nic,macaddr=00:16:3e:5e:f4:94,vlan=0 -net tap,fd=17,script=,vlan=0,ifname=vnet4
-net nic,macaddr=00:16:3e:6a:8a:a7,vlan=1 -net
tap,fd=18,script=,vlan=1,ifname=vnet5 -serial pty -parallel none -usb -vnc
127.0.0.1:0 
char device redirected to /dev/pts/3
char device redirected to /dev/pts/4

SELinux: enabled enforcing targeted, virtinst produces bunch of such avc: 
denied  { read write } for  pid=18723 comm="iptables" path="/dev/net/tun"
dev=tmpfs ino=1895 scontext=unconfined_u:system_r:iptables_t:s0
tcontext=system_u:object_r:tun_tap_device_t:s0 tclass=chr_file
Comment 3 Daniel Berrange 2008-06-16 16:41:12 EDT
Can you see if it also fails with SELinux in 'permissive' mode.
Comment 4 Alan Pevec 2008-06-16 16:47:20 EDT
Yes, it also fails after setenforce 0

BTW: virt-install cmdline in comment 2 is from a 64bit box while original log is
from other, 32bit box - but the same issue happened on both.
Comment 5 Daniel Berrange 2008-06-16 17:02:36 EDT
Can you capture an strace of the libvirtd daemon while you create the VM,


  strace -p <PID of libvirtd>   -s 30000 -o libvirt.log -f

Start the strace just before running virt-install, and stop it after the VM has
failed, then atach the log to this ticket
Comment 6 Chris Lalancette 2008-06-17 06:04:24 EDT
Created attachment 309586 [details]
Output from strace from previous comment.
Comment 7 Chris Lalancette 2008-06-19 06:08:16 EDT
*** Bug 451784 has been marked as a duplicate of this bug. ***
Comment 8 Chris Lalancette 2008-06-19 06:09:53 EDT
This has to do with the (mis-)allocate of tap fds during qemu startup.  I've
posted a patch to fix it here:

https://www.redhat.com/archives/libvir-list/2008-June/msg00213.html

Chris Lalancette
Comment 9 David Mueller 2008-06-26 01:05:29 EDT
I am seeing the same issue with libvirt-0.4.3-1.fc8 on Fedora 8.
Comment 10 Alan Pevec 2008-06-26 02:18:20 EDT
try libvirt-0.4.4-1.fc8 - in testing now
https://admin.fedoraproject.org/updates/F8/FEDORA-2008-5718
Comment 11 Fedora Update System 2008-06-26 04:29:23 EDT
libvirt-0.4.4-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libvirt'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5736
Comment 12 David Mueller 2008-06-27 18:59:14 EDT
libvirt-0.4.4-1.fc8 didn't fix problem for me.
Comment 13 David Mueller 2008-06-29 21:12:12 EDT
libvirt-0.4.4-1.fc8 is working for me now.  I suspect I neglected to restart libvritd after installing the 
update.
Comment 14 Fedora Update System 2008-07-01 01:30:08 EDT
libvirt-0.4.4-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.