search for: dynamic_ownership

Hi, I'm playing with dynamic ownership and not all objects have their owners changed. Is dynamic_ownership and its scope documented somewhere, besides the comment in qemu.conf? And what kinds of objects are handled by dynamic ownership? While some objects seem to be handled, other objects are apparently unaffected. For instance /dev/hwrng or a USB host device keep their root owners and are inaccessibl...

Hi, I am getting following 'qemu: could not load kernel' error while trying to create a new VM using virt-install or virt-manager. The software versions are as follows: CentOS 6.2, Libvirt 0.9.4, qemu-kvm 2:0.12.1.2-2.209.el6_2.1. The qemu.conf has disabled dynamic_ownership setting. The VM instantiation has worked fine before when dynamic_ownership was enabled (default). So is this error related to dynamic ownership being disabled? I appreciate any help on how to debug this error further. Also, is there any documentation on why/when dynamic_ownership setting should...

Hi, I'm having troubles with volume ownership. When I configure domain with disk type='file', dynamic_ownership works fine, the owner of image file changes into libvirt-qemu:kvm. However when I add the image file as a libvirt volume (in default pool) and configure domain with disk type=volume, the owner of image file remains root:root. Actually, libvirt seems to be changing the owner into root:root even afte...

On 09/19/2018 12:39 PM, Milan Zamazal wrote: > Hi, I'm playing with dynamic ownership and not all objects have their > owners changed. > > Is dynamic_ownership and its scope documented somewhere, besides the > comment in qemu.conf? > > And what kinds of objects are handled by dynamic ownership? While some > objects seem to be handled, other objects are apparently unaffected. > For instance /dev/hwrng or a USB host device keep their root o...

Hi Everyone: I am trying to create a volume using the vol-create-as command but it fails with an "Operation not permitted" error. It appears to be caused by an attempt to run chown on an NFS mounted file system but I have set dynamic_ownership to 0 in /etc/qemu.conf. Is it possible to disable the chown operation? If not, is there a guide that describes how to create storage pools on NFS filers? I have read http://libvirt.org/storage.html but there was no discussion of to work around this problem. Any help would be greatly apprec...

...31 PM, Milan Zamazal wrote: > Michal Prívozník <mprivozn@redhat.com> writes: > >> On 09/19/2018 12:39 PM, Milan Zamazal wrote: >>> Hi, I'm playing with dynamic ownership and not all objects have their >>> owners changed. >> >>> >>> Is dynamic_ownership and its scope documented somewhere, besides the >>> comment in qemu.conf? >>> >>> And what kinds of objects are handled by dynamic ownership? While some >>> objects seem to be handled, other objects are apparently unaffected. >>> For instance /dev/hwrng...

Michal Prívozník <mprivozn@redhat.com> writes: > On 09/19/2018 12:39 PM, Milan Zamazal wrote: >> Hi, I'm playing with dynamic ownership and not all objects have their >> owners changed. > >> >> Is dynamic_ownership and its scope documented somewhere, besides the >> comment in qemu.conf? >> >> And what kinds of objects are handled by dynamic ownership? While some >> objects seem to be handled, other objects are apparently unaffected. >> For instance /dev/hwrng or a USB host devi...

...om/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c16482496875afc0d37b181487ae46R1 3) When using libvirt it changes the owner of our image If we try to use libvirt, it changes the ownership of our QEMU images (root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and switch the option dynamic_ownership to “0”. What is the impact of that change? Is it dangerous? There is a way to avoid this change? Finally, here is the full code of the libvirt part: https://github.com/rodrigosiqueira/kworkflow/pull/23/files Thanks Best Regards -- Rodrigo Siqueira http://siqueira.tech Graduate Student Departmen...

...dir='/media/share'/> <target dir='data'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </filesystem> /etc/libvirt/qemu.conf : user = "root" group = "root" dynamic_ownership = 0 clear_emulator_capabilities = 0 even with this unsecure configuration I wasn't able to achieve that newly created files/dirs in guest machine have ownership of guest machine user but they are still created under root user id. Also strange is that group of those files/dirs are correct. Can...

...75afc0d37b181487ae46R1 > > > > 3) When using libvirt it changes the owner of our image > > > > If we try to use libvirt, it changes the ownership of our QEMU images > > (root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and > > switch the option dynamic_ownership to “0”. What is the impact of that > > change? Is it dangerous? There is a way to avoid this change? > > > > dynamic_ownership=0 keeps the owners as they are, but libvirt cannot guarantee > that the VM will have access to all its resources. If you are taking care of > tha...

Hi! I'm oVirt developer responsible for most of 'hostdev' support. While working on SCSI passthrough (that is hostdev type='scsi'), I've encountered few issues I'm not sure how to solve somewhat effectively and nicely. Just a note - oVirt by default disables 'dynamic_ownership', meaning we have to handle endpoint ownership/labeling ourselves. This is not something I can change in a short term. Also, oVirt uses libvirt's python API, I'll do my best using the original C names. To report and construct the hostdev element, I am using virConnectListAllNodeDevices...

...flow/pull/23/files#diff-d8c16482496875afc0d37b181487ae46R1 > >3) When using libvirt it changes the owner of our image > >If we try to use libvirt, it changes the ownership of our QEMU images >(root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and >switch the option dynamic_ownership to “0”. What is the impact of that >change? Is it dangerous? There is a way to avoid this change? > dynamic_ownership=0 keeps the owners as they are, but libvirt cannot guarantee that the VM will have access to all its resources. If you are taking care of that, then keeping that turned off...

...><div>user = "libvirt-qemu"<br>group = "libvirt"</div> <div># Whether libvirt should dynamically change file ownership<br># to match the configured user/group above. Defaults to 1.<br># Set to 0 to disable file ownership changes.<br>#dynamic_ownership = 1</div></div> <div dir="ltr" >&nbsp;</div> <div dir="ltr" >However, when I shutdown the domain, the file permissions revert to root.</div> <div dir="ltr" >&nbsp;</div> <div dir="ltr" >$ ll t257kv...

...; command and it was creating it under libvirt-qemu group which was a bit better. This new command is way more handy but if I can't sort this issue out I'll need to fallback to the previous one. I set in /etc/libvirt/qemu.conf the keys user = "myuser" group = "mygroup" dynamic_ownership = 1 And restarted libvirtd. > > Although, I'm wondering if we should not disregard this and make > coredump be always owned by root:root since a coredump may contain > sensitive info, e.g. all kinds of cipher keys. We do that with disk > images, so maybe we should reconsider o...

.../qemu.conf: >> >> user = "libvirt-qemu" >> group = "libvirt" >> # Whether libvirt should dynamically change file ownership >> # to match the configured user/group above. Defaults to 1. >> # Set to 0 to disable file ownership changes. >> #dynamic_ownership = 1 >> >> However, when I shutdown the domain, the file permissions revert to root. >> >> $ ll t257kvxg-10-20-101-40.qcow2 >> -rw-r--r-- 1 root root 2282749952 Mar 20 11:20 >> t257kvxg-10-20-101-40.qcow2 >> >> I expect libvirt to revert the file permi...

...ed on the settings in /etc/libvirt/qemu.conf: > >user = "libvirt-qemu" >group = "libvirt" ># Whether libvirt should dynamically change file ownership ># to match the configured user/group above. Defaults to 1. ># Set to 0 to disable file ownership changes. >#dynamic_ownership = 1 > >However, when I shutdown the domain, the file permissions revert to root. > >$ ll t257kvxg-10-20-101-40.qcow2 >-rw-r--r-- 1 root root 2282749952 Mar 20 11:20 t257kvxg-10-20-101-40.qcow2 > >I expect libvirt to revert the file permissions back to the original. >Otherwis...

On Fri, May 31, 2013 at 3:55 PM, Richard W.M. Jones <rjones@redhat.com>wrote: > On Fri, May 31, 2013 at 10:58:30AM +0800, Qiu Yu wrote: > > Unfortunately, the standard 'disk' group permission only applies to > > /dev/sdX device nodes, not to device mapper nodes created by LVM > commands. > > Actually, it depends on udev rules. On my machine device mapper

...it under libvirt-qemu group which was a bit better. This new command is way more handy but if I can't sort this issue out I'll need to fallback to the previous one. > > I set in /etc/libvirt/qemu.conf the keys > > user = "myuser" > group = "mygroup" > dynamic_ownership = 1 > > And restarted libvirtd. > >> >> Although, I'm wondering if we should not disregard this and make >> coredump be always owned by root:root since a coredump may contain >> sensitive info, e.g. all kinds of cipher keys. We do that with disk >> ima...

I'm working on an integration that uses QCOW2 volumes with backing stores. I have qemu configured to run as the "qemu" user, which seems to be fine. I now need to make sure my volumes are readable by this user. However, it seems the volume being created is owned by root, instead of "qemu" as I'd expect it to be. I tried various things and was unable to get it to create

...was* a raw image. Then a qcow2 overlay was > added, but the vm (which accesses the overlay file) only boot if the base > file is writable. I suspect this is a permission problem. The backing file still needs to be accessed by the VM so libvirt should correctly relabel it (if possible) if the dynamic_ownership feature is enabled. Since you are seeing problems it's possible that libvirt's treatment was not enough. Libvirt's labelling e.g. does not ensure that the directory user/group/label are correct, we only deal with the image. As the messages you've shared have obfuscated paths I can&...