please first check the domain is running under privileged system instance of the libvirt, and not just under oneadmin’s own session instance, by specifying a connection URI:
Last question. I found following files:
[root@xen2 libvirt]# pwd
/etc/libvirt
[root@xen2 libvirt]# ls -l qemu.conf*
-rw-r–r--. 1 root root 60 Nov 11 20:34 qemu.conf
-rw-r–r-- 1 root root 26771 Nov 14 15:53 qemu.conf.orig
[root@xen2 libvirt]#
I suppose file qemu.conf was created by opennebula installation and according its content:
[root@xen2 libvirt]# cat ./qemu.conf
user = “oneadmin”
group = “oneadmin”
dynamic_ownership = 0
[root@xen2 libvirt]#
“oneadmin” only user can install and operate VM. I’ve changed “oneadmin” to “root” (privileged user). Now I’m interesting will this changes affect to entire opennebula’s work?
it’s not quite the user who can install/operate VM (actually, the user who can access the libvirt interface can operate VMs), but the identity QEMU/KVM process is running. This is usually some unprivileged user (e.g. qemu), in this case it was changed for the OpenNebula to the oneadmin as it needs access to the oneadmin’s home. It’s (probably in all cases) bad idea to have KVM running with highest privileges, I don’t have tested now what will/won’t work in this mode.
Maybe describe better your intentions and we can find some better solution than using root.
Hello Vlastimil,
I’ve finally got what are you trying to explain me. I’ve set qemu user back to “oneadmin” and just start virt-install with key “–connect qemu:///system”. Now VM placed in system instance and can be easily imported to OpenNebula. Now it’s clear for me!