Tengo una PC en la que hago pruebas diversas y siguiendo un curso no pude avanzar por una cuestión de permisos.
Tenía que crear una máquina virtual temporal y para eso podría haber usado VirtualBox sin problemas y seguir con el curso pero quería aprender un poco sobre como hacerlo con QEMU/KVM.
Leí documentación y algunas páginas sobre la instalación de KVM usando CentOS 7.6 y resolví unos pormenores de la instalación de los cuales no tomé nota pero aún conservo la historia de los comandos (me disculpo de antemano, posiblemento alguno sea incorrecto.
yum whatprovides virt-manager
yum install virt-manager
systemctl status libvirtd
yum whatprovides libvirtd.service
yum whatprovides libvirtd
yum search libvirt-daemon
yum install libvirt-daemon.x86_64
systemctl status libvirtd
systemctl start libvirtd
systemctl status libvirtd
systemctl is-enabled libvirtd.service
systemctl is-active libvirtd.service
yum install virt-manager
systemctl status libvirtd
yum whatprovides libvirtd.service
yum whatprovides libvirtd
yum search libvirt-daemon
yum install libvirt-daemon.x86_64
systemctl status libvirtd
systemctl start libvirtd
systemctl status libvirtd
systemctl is-enabled libvirtd.service
systemctl is-active libvirtd.service
yum -y install qemu-kvm qemu-img virt-manager libvirt libvirt-python python-virtinst libvirt-client virt-install virt-viewer
Les sugiero que busquen y comparen los comandos previos para que tengan la seguridad de que harán lo correcto.
Al seguir los pasos del curso, me encontré con los primeros errores relacionados a permisos (les debo el mensaje de error, fue muy diferente de lo que mostraré al final) y creí que era porque el usuario/grupo "root" tenían los permisos sobre el sistema de archivos que es un disco secundario formateado y montado como NTFS:
/dev/sdb2 /mnt/vms ntfs-3g users,permissions 0 0
/dev/sdb2 /mnt/vms ntfs-3g users,permissions 0 0
Buscando de nuevo me encontré con la sugerencia de modificar la configuración de "polkit" para evitar que virt-manager me preguntara la contraseña del usuario "root". La respuesta la encontré aquí repito los pasos y secciones del texto por si llegara a desaparecer el sitio:
"Virt-manager y libvirt son herramientas utilizadas para la virtualización en el ecosistema de Linux. Como usuario final, estoy usando estas herramientas para crear y ejecutar máquinas virtuales. Estoy ejecutando estas herramientas como usuario normal sin usar un usuario privilegiado como root. Pero cada vez que intento ejecutar estas herramientas, sudo me pide la contraseña....."
La solución del autor original paso a paso:
"Polkit
PolicyKit o simplemente Polkit es un componente utilizado para controlar los privilegios de todo el sistema en sistemas operativos Unix y Linux. La distribución de Linux de Fedora utiliza mucho Polkit. Usaremos Polkit para autenticarnos y comenzar a usar virt-manager sin contraseña."
PolicyKit o simplemente Polkit es un componente utilizado para controlar los privilegios de todo el sistema en sistemas operativos Unix y Linux. La distribución de Linux de Fedora utiliza mucho Polkit. Usaremos Polkit para autenticarnos y comenzar a usar virt-manager sin contraseña."
"Crear grupo para la virtualización
Para ejecutar los servicios y el software de virtualización necesitamos un grupo que tenga derecho a acceder a los recursos del sistema relacionados. La mayoría de los sistemas operativos crean este grupo como libvirt. Si no es así crea el grupo con el siguiente comando. Pero tenga en cuenta que esto necesita privilegios de root."
Para ejecutar los servicios y el software de virtualización necesitamos un grupo que tenga derecho a acceder a los recursos del sistema relacionados. La mayoría de los sistemas operativos crean este grupo como libvirt. Si no es así crea el grupo con el siguiente comando. Pero tenga en cuenta que esto necesita privilegios de root."
groupadd libvirt
Ahora necesitamos poner a nuestro usuario normal o actual en el grupo de virtualización. Como se indicó en el paso anterior, el nombre del grupo es libvirt, pero si es diferente, cambie en consecuencia. En este comando, agregamos un grupo secundario llamado libvirt al usuario john"
$ sudo usermod -a -G libvirt john"
"Crear Regla de Polkit
Crearemos la regla de polkit usando el grupo libvirt. Crear un archivo como
/etc/polkit-1/rules.d/80-libvirt.rules
Y poner el siguiente contenido en el archivo. Esta regla dará a los usuarios de los grupos libvirt acceso a las capacidades de virtualización sin contraseña."
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("libvirt")) {
return polkit.Result.YES;
}
});
Lo siguiente que _yo_ hice fue reiniciar el servicio de polkit:
systemctl restart polkit
systemctl status polkit
Traté de crear la máquina virtual y exitosamente no me pedía la contraseña de root, pero seguía con el problema de permisos en otra parte:
"qemu-kvm: -drive file drive-virtio-disk0: could not open disk image"
y
"qemu-kvm: could not open disk image ' ': Permission denied"
Buscando encontré otra solución aquí :
"SOLVED: found a way.
Changing /etc/libvirt/qemu.conf to make things work.
Uncomment user/group to work as root.
Then restart libvirtd"
cat /etc/libvirt/qemu.conf | grep -v "#"user = "john"
group = "qemu"
# service libvirtd restart
Stopping libvirtd daemon: [ OK ]
Starting libvirtd daemon: [ OK ]
A pesar de ésta opción seguía con mensajes de error relacionado a los permisos.
Encontré éste comentario donde explican sobre los permisos de los sistemas de archivos y eso me recordó que pueden configurados desde el archivo /etc/fstab usando getfacl/setfacl y aún tenía el problema de los permisos.
El archivo /etc/fstab lo dejé modificado de la siguiente manera:
/dev/sdb2 /mnt/vms ntfs-3g defaults,nls=utf8,umask=000,dmask=000,fmask=000,uid=1000,gid=1000,windows_names 0 0
pero lo dejé como lo tenía al inicio originalmente:
/dev/sdb2 /mnt/shared ntfs-3g users,permissions 0 0
Preguntando en un grupo de telegram, me hicieron la sugerencia de agregar mi usuario a otros grupos:
usermod -a -G john,wheel,libvirt,polkitd,kvm,qemu john
Sin embargo el error se mantenía:
Unable to complete install: 'internal error: qemu unexpectedly closed the monitor: 2019-06-20 06:00:37.981+0000: Domain id=1 is tainted: high-privileges
2019-06-20T06:00:38.137358Z qemu-kvm: -drive file=/mnt/vms/t1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: could not open disk image /mnt/tests/KVM-VMs/servert1.qcow2: Could not open '/mnt/vms/t1.qcow2': Permission denied'
Hasta el día de hoy que sin sueño acumulado, un poco más temprano que en días previos tratando de solucionar otro problema con ésta computadora de prueba, en /var/log/messages he visto las soluciones:
setroubleshoot: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /mnt/vms/t1.qcow2
python: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /mnt/vms/t1.qcow2
Plugin qemu_file_image (53.1 confidence) suggests If servert1.qcow2 is a virtualization target Then you need to change the label on servert1.qcow2
Do: semanage fcontext -a -t virt_image_t '/mnt/vms/t1.qcow2' restorecon -v '/mnt/vms/t1.qcow2
Plugin catchall_boolean (42.6 confidence) suggests ******************
If you want to allow virt to use fusefs Then you must tell SELinux about this by enabling the 'virt_use_fusefs' boolean.
Do: setsebool -P virt_use_fusefs 1*****
Plugin catchall (5.76 confidence) suggests **************************
If you believe that qemu-kvm should be allowed open access on the t1.qcow2 file by default. Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing: ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -i my-qemukvm.pp
¿cuál opción deben usar? Eso depende del como administren su equipo.
No hay comentarios.:
Publicar un comentario