Bug 451709

Summary: starting domain fails with Unable to open monitor path /dev/pts/...
Product: [Fedora] Fedora Reporter: Alan Pevec <apevec>
Component: libvirtAssignee: Daniel Berrange <berrange>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: berrange, clalance, dsm42
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: ---
Bug Depends On:    
Bug Blocks: 451784    
Attachments:
Description Flags
Output from strace from previous comment. none

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.