Astra linux virt manager access denied

Содержание

Arch Linux
Создание ВМ через virt-manager
Fd1501h
Mkolomiets
Andrew
Andrew
Virt-manager Permission Denied when accessing NFS pool
1 Answer 1
Saved searches
Use saved searches to filter your results more quickly
Permission Denied when trying to start using virt-manager (Arch) #45
Permission Denied when trying to start using virt-manager (Arch) #45
Comments

Arch Linux

Unable to complete install: ‘internal error: process exited while connecting to monitor: char device redirected to /dev/pts/1 (label charserial0)
qemu-system-x86_64: -drive file=/home/r0b0t/KVM/yunohost/yunohostv2-latest-amd64-test.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /home/r0b0t/KVM/yunohost/yunohostv2-latest-amd64-test.iso: Permission denied

Traceback (most recent call last):
File «/usr/share/virt-manager/virtManager/asyncjob.py», line 100, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File «/usr/share/virt-manager/virtManager/create.py», line 1920, in do_install
guest.start_install(False, meter=meter)
File «/usr/share/virt-manager/virtinst/Guest.py», line 1134, in start_install
noboot)
File «/usr/share/virt-manager/virtinst/Guest.py», line 1202, in _create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File «/usr/lib/python2.7/site-packages/libvirt.py», line 2886, in createLinux
if ret is None:raise libvirtError(‘virDomainCreateLinux() failed’, conn=self)
libvirtError: internal error: process exited while connecting to monitor: char device redirected to /dev/pts/1 (label charserial0)
qemu-system-x86_64: -drive file=/home/r0b0t/KVM/yunohost/yunohostv2-latest-amd64-test.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /home/r0b0t/KVM/yunohost/yunohostv2-latest-amd64-test.iso: Permission denied

The iso permission is set to 777
I tried also changing the qemu.conf group to kvm,
I tried like everything but still no joy.

Last edited by r0b0t (2013-09-27 19:00:41)

Источник

Создание ВМ через virt-manager

Пробую создать ВМ через virt-manager, при запуске ВМ в логах ошибка:
3627: error : virDomainOpenConsoleEnsureACL:4270 : access denied
3627: error : virDomainOpenConsoleEnsureACL:4270 : access denied
3630: error : virDomainOpenConsoleEnsureACL:4270 : access denied
3626: error : virDomainSuspendEnsureACL:5658 : access denied

Astra Linux SE 1.6 (smolensk) установлена базовая версия с графикой, мандатные права полностью отключены.
Установлены пакеты:
apt-get install virt-manager libvirt-daemon-system libvirt0
пользователь запускающий virt-manager входит в группы:
adminuser cdrom floppy audio dip video plugdev netdev lpadmin scanner kvm libvirt libvirt-qemu libvirt-admin astra-admin astra-console

Fd1501h

Moderator

Mkolomiets

New member

Andrew

New member

Andrew

New member

Отвечу сам себе:
В ОССН мандатный контроль целостности по умолчанию отключён — всем сущностям ОССН назначается низкий уровень целостности. Для включения мандатного контроля целостности необходимо отредактировать скрипт инициализации файловой системы /usr/sbin/pdp-init-fs.

Источник

Virt-manager Permission Denied when accessing NFS pool

I’m currently having this error
when I’m trying to install a Virtual Machine on my NFS share. i’ve added my NFS share (coming from FreeNAS) to a Storage Pool on the virt-manager Another issue is that I can’t seem to read my ISO files from another NFS share either aswell. Hopefully you can solve this issue. I’ve tried the following:

qemu.conf — uncomment the user to force root user
mapall user to root in my freenas share (all users get the root permission)

1 Answer 1

The problem most probable is not related to Freenas nfs rights but to the selinux (or apparmor if you use Ubuntu) config of the host.

SELinux basic confinement The basic SELinux protection for QEMU virtual machines is intended to protect the host OS from a compromised virtual machine process. There is no protection between guests.

In the basic model, all QEMU virtual machines run under the confined domain root:system_r:qemu_t. It is required that any disk image assigned to a QEMU virtual machine is labelled with system_u:object_r:virt_image_t. In a default deployment, package vendors/distributor will typically ensure that the directory /var/lib/libvirt/images has this label, such that any disk images created in this directory will automatically inherit the correct labelling. If attempting to use disk images in another location, the user/administrator must ensure the directory has be given this requisite label. Likewise physical block devices must be labelled system_u:object_r:virt_image_t.

Not all filesystems allow for labelling of individual files. In particular NFS, VFat and NTFS have no support for labelling. In these cases administrators must use the ‘context’ option when mounting the filesystem to set the default label to system_u:object_r:virt_image_t. In the case of NFS, there is an alternative option, of enabling the virt_use_nfs SELinux boolean.

To check if the right labels are there do an ls -Z on the directory where you store the VM images.

Читайте также: Setup php on linux

To enable nfs access to the vm’s you need to use:

setsebool virt_use_nfs on

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission Denied when trying to start using virt-manager (Arch) #45

Comments

Runs fine when I just run basic.sh, but when I try to start it in virt-manager I get the following error:

Error starting domain: Cannot access storage file ‘~/macOS-Simple-KVM/ESP.qcow2’ (as uid:65534, gid:992): Permission denied

The text was updated successfully, but these errors were encountered:

What permissions do I give it? I chmod 755/777 and chown’d to myself but still get this error.

Try ugo+rx. Test that the qemu user can access the file with:
sudo -u qemu file /path/to/file

If you’re using SELinux or Apparmor it may be blocking access.
Spent an hour trying to figure out why I was getting permission errors on the firmware files before realizing this.

Another possible option is to modify the make script so that the disk image(s) get copied to Libvirt’s default location (e.g. /var/lib/libvirt/images/). This might save a lot of time messing with the system policy or doing something bad (like disabling SELinux).

@badmark ever git this resolved? Can you post what solution you used?
I have heard of one possible solution of adding your own user to a virtmanager group of some sort although I’m still investigating. It wasn’t a solution to this specific problem but supposedly helped reduce permission issues

@jessechahal I had the same problem and solved it by copying the folder over to /var/lib/libvirt/images like @adrianlshaw suggested.

It may have something to do with ownership but simply changing ownership to root just gave me permission problems for other files. Copying it to the images folder is the easiest solution as far as I can tell.

The entire folder? I moved the image then got firmware errors.

Yes, the entire folder. Also you need to checkout the correct firmware, there’s another issue that describes that #15

I had the same issue that I managed to solve.

My notes on this (Ubuntu 19.10) :

sudo chown libvirt-qemu: /var/lib/libvirt/images/BaseSystem.img sudo chown libvirt-qemu: /var/lib/libvirt/images/macosdisk.qcow2

sudo ls -lah /var/lib/libvirt/images/ total 49G drwx--x--x 2 root root 4,0K déc. 7 15:02 . drwxr-xr-x 7 root root 4,0K déc. 9 14:09 .. -rw-r--r-- 1 libvirt-qemu kvm 2,0G déc. 9 14:26 BaseSystem.img -rw------- 1 libvirt-qemu kvm 47G déc. 9 14:43 macosdisk.qcow2

disk type='file' device='disk'> driver name='qemu' type='qcow2'/> source file='/opt/macOS-Simple-KVM/ESP.qcow2'/> target dev='sda' bus='sata'/> address type='drive' controller='0' bus='0' target='0' unit='0'/> disk> disk type='file' device='disk'> driver name='qemu' type='qcow2'/> source file='/var/lib/libvirt/images/macosdisk.qcow2'/> target dev='sdb' bus='sata'/> address type='drive' controller='0' bus='0' target='0' unit='1'/> disk> disk type='file' device='disk'> driver name='qemu' type='raw'/> source file='/var/lib/libvirt/images/BaseSystem.img'/> target dev='sdc' bus='sata'/> address type='drive' controller='0' bus='0' target='0' unit='2'/> disk>

Always verify that firmware/OVMF_CODE.fd and firmware/OVMF_VARS-1024×768.fd exist because they might have been deleted (I had to wget https://github.com/foxlet/macOS-Simple-KVM/raw/master/firmware/OVMF_VARS-1024×768.fd few times)
To verify that libvirt can access your files (correct rights + file exist)

sudo -u libvirt-qemu file /var/lib/libvirt/images/macosdisk.qcow2 \ /var/lib/libvirt/images/BaseSystem.img \ /opt/macOS-Simple-KVM/firmware/OVMF_CODE.fd \ /opt/macOS-Simple-KVM/firmware/OVMF_VARS-1024x768.fd /var/lib/libvirt/images/macosdisk.qcow2: QEMU QCOW2 Image (v3), 68719476736 bytes /var/lib/libvirt/images/BaseSystem.img: DOS/MBR boot sector; partition 1 : start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 1, 4187063 sectors, extended partition table (last) /opt/macOS-Simple-KVM/firmware/OVMF_CODE.fd: data /opt/macOS-Simple-KVM/firmware/OVMF_VARS-1024x768.fd: data

Once every thing is ready create the VM in Virt-manager with virsh define —file template-custom.xml

Источник