Red Hat Bugzilla – Bug 511179
svirt errors causing qemu guests to fail to start
Last modified: 2009-08-20 13:26:43 EDT
Description of problem:
Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open monitor device 'pty'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/create.py", line 1501, in do_install
dom = guest.start_install(False, meter = meter)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 541, in start_install
return self._do_install(consolecb, meter, removeOld, wait)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 633, in _do_install
self.domain = self.conn.createLinux(install_xml, 0)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1073, in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty'
Version-Release number of selected component (if applicable):
(This has the new polkit changes for various components like gnome, etc. There seem to have been some strangeness with it. Running as a regular user, but made sure that system/prefs/authorizations for virt were assigned to the user, selinux is off)
Not sure if this belongs to qemu
Tried to create a new F11 virtual machine
Steps to Reproduce:
I've seen this too, though my rawhide box crapped out before I could really investigate it. Has something to do with recent change to drop capabilities: if I recompiled with --with-capng=no, the errors stopped. So this is probably one for danpb.
(In reply to comment #1)
> I've seen this too, though my rawhide box crapped out before I could really
> investigate it. Has something to do with recent change to drop capabilities: if
> I recompiled with --with-capng=no, the errors stopped. So this is probably one
> for danpb.
you're right, I can confirm this, but the bug is in libvirt, not in virt-manager, you have reported the bug to wrong package.
Do you have anything in /var/log/libvirt/qemu/$GUEST.log ?
Also could you attach the XML config for a guest exhibiting the problem, and your /etc/libvirt/qemu.conf file.
Created attachment 355272 [details]
conf file (unchanged from the standard install)
Created attachment 355273 [details]
guest log file
There are two entries because I hit the "finish" button twice (rather than cancel the second time)
Can you tell me where the XML config file would be stored? I hunted around for a bit, including the man pages, but can't find them.
Note that the image files from the failed attempts should probably be removed. I don't think they're accessible afterwards.
The config is in /etc/libvirt/qemu/$GUEST.xml, or even better just use 'virsh dumpxml GUEST' since that tells you exactly what libvirtd knows.
If you have SELinux in enforcing mode, could you also try with 'setenforce 0' to see if that makes any difference.
Finally, there will shortly be a new libvirt 0.7.0 appearing in rawhide which could be worth trying, unless i discover the problem soon...
The only thing in the /etc/libvirt/qemu directory is a networks directory.
I can't find an option in virsh that just lists the valid domains (but there aren't any anyway)
This was a fresh F11 install, so this is the first guest I've tried to create on this physical machine.
SELinux? ewwww. I mean... I don't run selinux.
I'm in no hurry, so will happily wait for the 0.7.0 version. Let me know if you have anything else you want me to look at in the mean time.
Oh of course there's no config, since you didn't actually successfully launch your first VM !
You were using virt-manager, so if you provide the $HOME/.virt-manager/virt-manager.log file that will be sufficient to show us the config.
(In reply to comment #7)
> Finally, there will shortly be a new libvirt 0.7.0 appearing in rawhide which
> could be worth trying, unless i discover the problem soon...
let me know when it available and I will test it.
Created attachment 355309 [details]
vir manager log file from failed install
Same error with libvirt-0.7.0-0.2.gitf055724.fc12.x86_64
I'm getting the same error on Fedora 11 after applying today's updates, the only relevant packages in the updates were:
After configuring SELinux as permissive the virtual machines were able to boot fine just as yesterday.
My virtualization packages are:
Damn!!! after booting, my virtual machines are unable to connect to the network.
This is really bad!.
Seeing this issue as well after latest rawhide updates.
I'm able to start my existing guests with selinux in permissive mode. However, when I attempt to start my guests in enforcing mode, I see the following AVC messages:
# setroubleshoot: SELinux prevented qemu-kvm from using the terminal 1. For complete SELinux messages. run sealert -l 3541fc17-e3ca-451a-b377-980508853f55
* AVC logged at http://fpaste.org/ktt8/
# setroubleshoot: SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. For complete SELinux messages. run sealert -l 82f80418-ebe4-4189-99af-c9e5a71cc453
* AVC logged at http://fpaste.org/ibhn/
# setroubleshoot: SELinux is preventing qemu-kvm (svirt_t) "fsetid" svirt_t. For complete SELinux messages. run sealert -l 3145e077-df77-46de-9c1f-2e1370312d36
* AVC logged at http://fpaste.org/OZCy/
I've made the boolean correction suggested in the first AVC, but the problem remains.
As the original bug reporter, I've always run with selinux off.
I'm using today's rawhide. The new guest dialog gets past the pty problem now.
The bochs emulator comes up in text mode but now it can't find the cdrom.
brw-rw----+ 1 qemu qemu 11, 0 2009-08-10 14:18 /dev/sr0
I'm running as a 'normal' user, giving the root password to start creating the virtual machine.
The setrlimit() one is in F-11 too - see bug #515521
dwalsh: any ideas?
A temporary fix is to rollback to glibc-2.10.1-2.
#yum downgrade glibc glibc-common glibc-headers glibc-devel
What do you get from "grep /dev/pts /etc/fstab"?
*** This bug has been marked as a duplicate of bug 515521 ***
If you fix your fstab entry and reboot, your virtual machines should work with SELinux in enforcing mode.
devpts /dev/pts devpts gid=5,mode=620 0 0
Daniel Walsh, that devpts /etc/fstab change fixed it for me... but what to do to resolve this more correctly? A libvirt package updated pending?
The /etc/fstab change is the most correct way to fix this.
Perhaps some package should try to edit /etc/fstab in its %post if it detects this bug.
Which is where we get into an argument about which package is correct, and realize that this patch will have to be carried until F11 dissapears.
There's no argument to be had - /etc/fstab is owned by 'setup'
$ rpm -qf /etc/fstab