Creating a guest OS whose name contain spaces causes it to fail

[orpiske]

Creating a guest OS whose name contain spaces causes Kimchi to fail to start the guest OS. The UI displays a message stating that it "Failed to start":

This is the Kimchid startup log:

[15/Jan/2014:12:29:47] HTTP 
Request Headers:
  COOKIE: kimchi=3a38037087445fd43b186a58eb0bee1953d055d2; userid=orpiske; token=windows7
  Remote-Addr: 127.0.0.1
  Content-Length: 0
  USER-AGENT: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
  CONNECTION: keep-alive
  REFERER: https://localhost:8001/
  PRAGMA: no-cache
  X-REQUESTED-WITH: XMLHttpRequest
  HOST: localhost:8001
  CACHE-CONTROL: no-cache
  ACCEPT: application/json, text/javascript, */*; q=0.01
  ACCEPT-LANGUAGE: en-us,en;q=0.7,pt-br;q=0.3
  Content-Type: application/json
  ACCEPT-ENCODING: gzip, deflate
[15/Jan/2014:12:29:47] HTTP Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cprequest.py", line 656, in respond
    response.body = self.handler()
  File "/usr/lib/python2.7/dist-packages/cherrypy/lib/encoding.py", line 188, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cpdispatch.py", line 34, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/home/orpiske/workspace/code/foss/kimchi/src/kimchi/control/base.py", line 70, in wrapper
    fn(*model_args)
  File "/home/orpiske/workspace/code/foss/kimchi/src/kimchi/model.py", line 579, in vm_start
    dom.create()
  File "/home/orpiske/workspace/code/foss/kimchi/src/kimchi/model.py", line 1771, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 620, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error cannot load AppArmor profile 'libvirt-61d77fad-bb1f-49fa-93e1-2b70a5cb8f4c'

I believe Kimchi should prevent users from using certain characters in the Guest OS name, just like Virtual Machine Manager does. Here's an attached image for reference:

[orpiske]

I have a patch for this issue. I am having problems to subscribe to the mailing list, but I will submit it as soon as I my request is approved/added to the list.

[cd1]

How can you tell that error was due to the space in the name? The error message doesn't mention that.

I am able to create and start a VM with a space in the name using Kimchi (I used "hello world"). And I am also able to do the same using virsh. So I don't think we should add this restriction.

Regarding the bug, I don't know what has caused it. It may be some interaction between Ubuntu's AppArmor and libvirt... but it cannot be the space itself, otherwise I would have hit this same error, or even virsh, when I set a VM with spaces.

I'm running Fedora 20.

[orpiske]

Well, renaming it fixes the problem:

What I think it's odd is that when I rename it with spaces, it causes Virtual Machine Manager to fail as well. Here's a sample:

With that said, I don't think it's a problem in Kimchi itself, and it's probably in libvirt or something else. However, given the fact that Virtual Machine Manager prevents the user from using spaces in the name of the guest OS, I think Kimchi should do the same.

[cd1]

Well, renaming it fixes the problem:

This may fix the problem but it may not be the best solution, specially when this solutions adds a limitation.

What I think it's odd is that when I rename it with spaces, it causes Virtual Machine Manager to fail as well.

If that's an internal libvirt error, it will happen indeed to every client which uses it under the hood (Kimchi, virt-manager, virsh).

With that said, I don't think it's a problem in Kimchi itself, and it's probably in libvirt or something else.

I also don't think it's a problem in Kimchi itself. The message says there's a conflict with AppArmor, we need to find out what is that exactly.

However, given the fact that Virtual Machine Manager prevents the user from using spaces in the name of the guest OS, I think Kimchi should do the same.

I don't think we should do something just because someone also does it, specially because this limits the possible VM names.

[orpiske]

What do you think would be an acceptable solution for / work-around this issue?

[cd1]

I was able to create and start VMs with spaces on Fedora and openSUSE, but not on Ubuntu. So the problem only seems to happen there. The error message shows that the AppArmor's profile related to libvirt could not be loaded. I don't know what exactly is AppArmor, I believe it's something like a firewall or SELinux combined... AppArmor might have some profile that's stopping libvirt from creating a VM with space in the name. I think the solution would be to understand exactly what's happening - I just wrote here what I think it might be - and to make AppArmor work nicely with libvirt. We can debug AppArmor's log, libvirt's interation with it through the profiles, etc.

As a last resort, we could apply that patch above (which blocks some VM name characters) only to Ubuntu. I really don't like the idea of restricting every single distro only because of Ubuntu as this seems to be a problem related to its own security layer, AppArmor. But even in that case, the patch doesn't actually fix the problem: you weren't able to create VMs with spaces, and after the patch, you're still not. So I think it's worth to debug this a little further and come up with a real solution.

[orpiske]

Maybe this can give us a hint about where to look at:

2014-01-22 23:15:15.193+0000: 2000: error : virCommandWait:2314 : internal error Child process (/usr/lib/libvirt/virt-aa-helper -p 0 -r -u libvirt-61d77fad-bb1f-49fa-93e1-2b70a5cb8f4c) status unexpected: exit status 1
2014-01-22 23:15:15.193+0000: 2000: error : AppArmorGenSecurityLabel:446 : internal error cannot load AppArmor profile 'libvirt-61d77fad-bb1f-49fa-93e1-2b70a5cb8f4c'
2014-01-22 23:15:15.194+0000: 2000: error : qemuRemoveCgroup:592 : internal error Unable to find cgroup for ubuntu_12_04 with spaces
2014-01-22 23:15:15.194+0000: 2000: warning : qemuProcessStop:4118 : Failed to remove cgroup for ubuntu_12_04 with spaces

[veduardo]

There is an "old" bug on launchpad where some users are reporting the exact same thing with QEMU and libvirt: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/799997
The issue has been confirmed as a bug in January 16, 2014, and seems that it's not fixed yet. =/

[orpiske]

I have posted a work-around in the dev PDL. You can disable virt-aa-helper so that it's not loaded by libvirtd. Here's what I sent:

While I couldn't test on newer Ubuntu versions due to lack a spare box, I think I found a solution /
work-around to this: disabling virt-aa-helper. Before I start, here's some background information
about it, taken from the AppArmor documentation:

"When a VM is started, libvirtd decides whether to ask virt-aa-helper to create a new profile or modify an existing one. If no profile exists, libvirtd asks virt-aa-helper to generate the new base profile, in this case /etc/apparmor.d/libvirt/libvirt-a22e3930-d87a-584e-22b2-1d8950212bac, which
it does based on /etc/apparmor.d/libvirt/TEMPLATE. Notice, the new profile has a profile name that is based on the guest’s UUID. Once the base profile is created, virt-aa-helper works the same for create and modify: virt-aa-helper will determine what files are required for the guest to run (eg kernel, initrd, disk, serial, etc), updates /etc/apparmor.d/libvirt/libvirt-a22e3930-d87a-584e-22b2-1d8950212bac.files, then loads the profile into the kernel."

Disabling it is pretty simple: you just have to set the security driver in /etc/libvirtd/qemu.conf to "none". Like this:
security_driver = "none"

After that, restart libvirt:
/etc/init.d/libvirt-bin restart

Now it starts without calling virt-aa-helper:

virsh # start 'ubuntu_12_04 with spaces'
Domain ubuntu_12_04 with spaces started

You may want to add that information to the documentation about this ... With a note that this may decrease the system's security.

We have to put this information on a wiki page.

[shaohef]

It can works well to start a VM whose name contain spaces on F20.
Does this bug is just on ubuntu?
@orpiske waiting for your patch?
you can subscribe to Kimchi-devel by this link.
http://lists.ovirt.org/mailman/listinfo/kimchi-devel

[shaohef]

It's Ubuntu's AppArmor limitation.
Should we work-around this issue for Ubuntu?

[shaohef]

If not, tag it with "wontfix" ?

[orpiske]

I submitted a patch, but since it's a Ubuntu limitation it does not make sense to accept it. That app armor behavior can be disabled by following the steps I provided above.

[hlogmans]

Hmm, ran into this issue (Ubuntu 14.04) after a (=compliment) flawless experience with kimchi. For new users, this can be typed as 'scary error'. Anyone considered to catch this error and amend it with the tip "Not all host OS-es can use spaces in the VM name". Then you don't have to change anything when this problem in Ubuntu is fixed, and don't have to impose restrictions on all users. And the error is much less scary ;-)

[ss23]

I am strongly in favor for adding a temporary restriction/notification when running on Ubuntu. The error is exceptionally hard to figure out for someone new to Kimchi.

[BentHaase]

As @ss23 told I ran into it. Without proper knowledge, this is a "never to be figured out" bug. Please add a restriction to the name field to disallow spaces.