issues accessing /sys/hypervisor/uuid when rebooting VM

[John Garbutt]

Reported as openstack question:
https://answers.launchpad.net/nova/+question/214413

Looks like you get "access denided" on /sys/hypervisor/uuid if you reboot a VM

Folsom in both Ubuntu 12.04 and 12.10 with XCP 1.6 beta 2.

I get access denied errors when I try to do anything with /sys/hypervisor/uuid and as a result, compute will not stat. I've spent all day researching and came up empty. It seems that the very first time I power on a new VM, I'm able to read it with cat. Once I reboot, no go. Checked permissions, running as su. I am completely stuck right now. I can access the type file that's in the same folder.

[Mohammed Naser (mnaser)]

Further investigation, first the type will always work because it just returns a string with zero processing.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=blob;f=drivers/xen/sys-hypervisor.c;h=1e0fe01eb6705dee98acd115be1ab781cdabbc10;hb=ba6c2f688e255a1f52f2930ae9e6d62ede804289#l37

When comparing this to upstream, there seems to be a much newer way of getting that information (and if it fails, fallback). Maybe because it's a bit problematic when using the most recent release of Xen to use the older method?

https://github.com/torvalds/linux/commit/5c13f8067745efc15f6ad0158b58d57c44104c25

This commit added a new hypercall of getting it with a fallback to the original, I would speculate that if that's added, it'll work in all scenarios.

[Bob Ball (bob-ball)]

We suspect it may be a permissions bug in the way xenstore is set up by XAPI.

# list_domains
id | uuid | state
 5 | 0dae370c-753d-5ef0-e3e0-e3a5e93d6203 | B

# xenstore-ls -fp | grep /vm/0dae370c-753d-5ef0-e3e0-e3a5e93d6203/uuid
/vm/0dae370c-753d-5ef0-e3e0-e3a5e93d6203/uuid = "0dae370c-753d-5ef0-e3e0-e3a5e93d6203" (n0,r1)

This suggests that even though the domain ID post-reboot has been updated, the xenstore permissions have not been updated (the domain was previously domain 1 - hence the r1 permission)

[Bob Ball (bob-ball)]

We've identified a workaround that can get the VM uuid:

root@ubuntulucidlynx1004:~# xenstore-read domid
2
root@ubuntulucidlynx1004:~# xenstore-read /local/domain/2/vm
/vm/6fddd486-b376-647d-d7d4-9acf0e164722

It is the /vm/<uuid> path which has the incorrect permissions, however the UUID is in /local/domain/<domid>/vm which is all that is needed for nova to identify itself to the host.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.