virDomainCreateLinux() failed Timed out while reading console startup output

Pressing Finish again worked fine; it created and started the virtual machine. Weird.

Sorry, I don't pressing Finish button again, the virt-manager application closed. I'm restarted and recreated the new virtual machine. It's works.

I'm not able to continue.
Trying to set up a machine with KVM/Qemu

Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 617, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 813, in start_install
    return self._do_install(consolecb, meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 834, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 585, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: virDomainCreateLinux() failed
'

AMD 64
Ubuntu 08.04 (alpha 5)

I get the exact same message:

Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 617, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 813, in start_install
    return self._do_install(consolecb, meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 834, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 585, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: virDomainCreateLinux() failed

AMD 64
Ubuntu 8.04 (alpha 5)
'

Hi, I had the same problem, to solve it I added my user to the "kvm" group and everything is working now. After add your user to the kvm group you have to log off an log in.

To solve execute:
sudo adduser [username] kvm

Best regards.

I can confirm this fixed the problem. The error message should tell the user this and be more informative.

I added my user to the kvm group but i get this error message:

Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 617, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 813, in start_install
    return self._do_install(consolecb, meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 834, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 585, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: virDomainCreateLinux() failed
'

Adding user to kvm won't help.

I also get this error. My username is part of the kvm group, that didn't fix it. Is this a AMD64-specific issue?

Using Hardy beta on AMD64 w/ restricted nvidia video driver.

I had the same issue on an up-to-date hardy x86-64, and adding myself to the 'kvm' group (plus logoff / logon again, don't forget that) fixed it. I was already a member of the 'libvirtd' group, which is apparently not enough...

It's not a 64 bit issue. I run a 32 bit maschine.

Ditto, 32 bit here too.

Either way, the app is not correctly checking for membership of both 'kvm'
and 'libvirtd' groups.

Mike

On Sun, Mar 30, 2008 at 8:38 AM, LordSavage <email address hidden> wrote:

> It's not a 64 bit issue. I run a 32 bit maschine.
>
> --
> virDomainCreateLinux() failed Timed out while reading console startup
> output
> https://bugs.launchpad.net/bugs/187048
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

debconf did not add my user to kvm or libvirtd groups. Added my user to both groups, logged out and back in but it still wouldn't work. Restarted and it is now working fine.

Contrary to my previous post, it looks like my username *wasn't* added to the correct groups. I was previously looking at the groups listed under the "Users and Groups" interface, and didn't realize that my user wasn't added. Is there any GUI for configuring users' groups? As posted above, I added myself to the correct groups, using:

sudo adduser {username} kvm
sudo adduser {username} libvirtd

Now I am able to create virtual machines as expected.

After adding user to group and reboot, it works here.

Issue is still up in RC, you still have to add yourself to the 2 groups.
Please fix this for the Final.
Thanks

You do not need to be a member of those two groups.

You need membership of libvirtd to manage the system-wide libvirtd instance (qemu:///system), and you need membership of kvm to run virtual machines as yourself (qemu:///session). If you're using virt-manager for other purposes, you don't even need to be a member of either.

For intrepid, I'll make sure the error messages are more helpful. I will not, however, be automatically adding users to any of these groups.

Thanks Soren - better error messages would, I think, satisfy everyone here.
Your efforts are truly appreciated.

Could the fix be applied to Hardy though? This seems like a usability bug,
and would be nice to have fixed in the Hardy's cycle.

Mike

On Wed, Apr 23, 2008 at 6:01 PM, Soren Hansen <email address hidden> wrote:

> You do not need to be a member of those two groups.
>
> You need membership of libvirtd to manage the system-wide libvirtd
> instance (qemu:///system), and you need membership of kvm to run virtual
> machines as yourself (qemu:///session). If you're using virt-manager for
> other purposes, you don't even need to be a member of either.
>
> For intrepid, I'll make sure the error messages are more helpful. I will
> not, however, be automatically adding users to any of these groups.
>
> --
> virDomainCreateLinux() failed Timed out while reading console startup
> output
> https://bugs.launchpad.net/bugs/187048
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I'm afraid changing this in hardy is waaay to late. String freeze was a long time ago.

Here's one approach to solving the problem, liberally borrowed from MythTV.

When running mythfrontend, it runs a script that checks if you're a member of the mythtv group, and if not, it warns you about this, and offers you the opportunity to enter your password, and it will try to use sudo to add you to the appropriate group.

I'm attaching a debdiff that adds just such a script, /usr/bin/virt-manager-check-groups. On launching virt-manager, it will loop through the groups (kvm, libvirtd, vde2-net), and if the group exists, it will check if the current user is a member.

<aside>
The bulk of the code is trying to figure out if you're running gnome or kde, and finding the correct helper applications. Really, it would be nice if this entire script were a nice little standalone tool of its own, taking any group as an input.
</aside>

Dustin - Thanks for the script, but unfortunately virt-manager can manage
VMs both locally and remotely - you wouldn't want someone to not be able to
run the app because they're not a memeber of the right group on their desktp
when they're actually intending to manage VMs on the server.

The correct thing, as Soren mentioned earlier, is to check for memberships
of the groups when the connections to domains requiring those groups are
needed. I believe Soren already has a fix for this.

Soren can you explain to me the string freeze? I was under the impression
that bug fixes caused by, or fixable by, string changes were acceptable
during the lifetime. Otherwise how would these bugs get fixed, especially
for an LTS release like Hardy?

Thanks muchly (and sorry if it seems like I'm stalking you!)

Mike

On Fri, Apr 25, 2008 at 2:03 PM, Dustin Kirkland <email address hidden>
wrote:

> Here's one approach to solving the problem, liberally borrowed from
> MythTV.
>
> When running mythfrontend, it runs a script that checks if you're a
> member of the mythtv group, and if not, it warns you about this, and
> offers you the opportunity to enter your password, and it will try to
> use sudo to add you to the appropriate group.
>
> I'm attaching a debdiff that adds just such a script, /usr/bin/virt-
> manager-check-groups. On launching virt-manager, it will loop through
> the groups (kvm, libvirtd, vde2-net), and if the group exists, it will
> check if the current user is a member.
>
> <aside>
> The bulk of the code is trying to figure out if you're running gnome or
> kde, and finding the correct helper applications. Really, it would be nice
> if this entire script were a nice little standalone tool of its own, taking
> any group as an input.
> </aside>
>
> ** Attachment added: "virt-manager-check-groups.debdiff"
> http://launchpadlibrarian.net/13880679/virt-manager-check-groups.debdiff
>
> --
> virDomainCreateLinux() failed Timed out while reading console startup
> output
> https://bugs.launchpad.net/bugs/187048
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Mike-

I can address that to some extent.

First of all, the script/popup that's included in my debdiff supports an "ignore" option. So it asks you if you want to be added to these groups, and if you click "no", it asks you if you want to be asked again in the future. If you tell it "no", an "ignoregroups" file is created in your ~/.virt-manager/, which is checked on load each time. This would help with the situation where you ONLY connect to remote VM hypervisors, from the nag factor.

If you're doing a remote tunnel over SSH, I might even be able to support remote addition to the groups.

But before I take this patch any further, I'd like to get Soren's opinion on the overall approach.

:-Dustin

I'm presently working this one.

:-Dustin

Updated patch attached.

This is a minimally-invasive patch that tests for read/write access to /dev/kvm at VM-creation time. If that access fails, an error message pops up, noting the permission/ownership problem, and suggesting an appropriate "sudo adduser ... kvm" command to solve it.

This is far simpler than the previous patch (which would actually attempt to do the adduser) in the interest of potentially attaining an SRU-approval for Hardy's .1 release.

:-Dustin

Updated patch.

I moved the code down a few blocks, such that we only test access to /dev/kvm if the "Enable kernel / hardware acceleration" checkbox is selected. This limits our scope correctly.

I also use os.access() to test permissions, rather than open(). This is much cleaner.

:-Dustin

Updated patch.

Per IRC conversation with Soren, two more changes to the previous patch.

1) Make sure the connection is against qemu:///session
2) use getpass.getuser() to obtain username

:-Dustin

There are packages in my PPA with the last patch applied.

I'd be interested in any testing feedback anyone might have.

https://launchpad.net/~kirkland/+archive
virt-manager - 0.5.3-0ubuntu10~ppa2

:-Dustin

Included in SRU: 0.5.3-0ubuntu10

You need to fix the i18n'ing of the string:

 msg = "..."
 error(_(msg))

does not work, since xgettext only scans for _('string'), and does not track variables. You need to use

  msg = _('...')
  error(msg)

This is really an edge case of an SRU, but I agree that unhelpful error messages drive users up the wall, so I'm ok with smuggling this in (it's a small patch),

However, Dustin's latest patch only tests for kvm membership. Weren't some of the reports due to not being in "libvirtd"? Or is http://launchpadlibrarian.net/13880679/virt-manager-check-groups.debdiff required in addition to http://launchpadlibrarian.net/14055096/virt-manager_test_kvm_perms.debdiff ?

On Tue, May 6, 2008 at 12:28 AM, Martin Pitt <email address hidden> wrote:
> You need to use
> msg = _('...')
> error(msg)

Thanks Martin. Admittedly, I was afraid of the i18n'ing of this, so
I'm not surprised there was a hiccup.

I'll leave this for Soren to fix, since he has commit access and can
knock this out trivially.

> However, Dustin's latest patch only tests for kvm membership. Weren't
> some of the reports due to not being in "libvirtd"? Or is
> http://launchpadlibrarian.net/13880679/virt-manager-check-groups.debdiff
> required in addition to http://launchpadlibrarian.net/14055096/virt-
> manager_test_kvm_perms.debdiff ?

Attachment 13880679 is deprecated by the latest version.

libvirtd membership is needed to attach to the qemu:///system instance only.

Note the conditional checks that the connection is to the
qemu:///session instance:
    if self.connection.get_uri() == "qemu:///session" and
self.get_domain_type() == "kvm":

Soren, perhaps we should have an elif that checks
self.connection.get_uri() == "qemu:///system" and checks libvirtd
membership, throwing up a similar error message in that case. Your
thoughts?

:-Dustin

libvirtd membership and kvm membership are different beasts and require different logic. You wouldn't be able to get to that elif code path, if you're not connected read/write to qemu:///system already anyway.

I'll fix the xgettext thing. libvirtd membership is for later.

Accepted into -proposed, please test and give feedback here

Thanks Martin, where do we get packages for -proposed?

On Mon, May 12, 2008 at 5:18 AM, Mike MacCana <email address hidden> wrote:
> Thanks Martin, where do we get packages for -proposed?

You need a couple of lines like this in your /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu/ hardy-proposed main restricted
deb-src http://archive.ubuntu.com/ubuntu/ hardy-proposed main restricted

apt-get update && apt-get upgrade virt-manager

Then remove or comment them out of your source.list when you're done
testing -proposed packages and apt-get update again.

:-Dustin

I can replicate the bug with the hardy final version. With hardy-proposed I get a proper error message.

Copied to hardy-updates. Please upload to intrepid ASAP.

Sorry about not updating the bug status. This was fixed long, lonng ago.