similar to: qemu - could not load kernel and dynamic ownership setting

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

Hi, My colleagues and I have a set of scripts that we use to automate our daily tasks related to the Linux Kernel. As a result, most of our code relies on the QEMU features; and recently we decided use libvirt instead of QEMU. However, we have some questions, and I would like to know if someone could help us. Follows: 1) Import our QEMU images with virsh Currently, we import the QEMU VMs with

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

Hello, I'm having an issue with usage of libvirt driven qemu where I'm sharing directory with guest machine. virsh domain filesharing configuration: <filesystem type='mount' accessmode='passthrough'> <driver type='path' wrpolicy='immediate'/> <source dir='/media/share'/> <target dir='data'/>

Hi, First of all, thanks for your feedback :) On 10/17, Martin Kletzander wrote: > On Wed, Oct 03, 2018 at 01:04:50PM -0300, Rodrigo Siqueira wrote: > > Hi, > > > > My colleagues and I have a set of scripts that we use to automate our > > daily tasks related to the Linux Kernel. As a result, most of our code > > relies on the QEMU features; and recently we

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

2015-05-28 12:04 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>: > On 28.05.2015 09:29, NoxDaFox wrote: > > Greetings, > > > > I am dumping a guest VM memory for inspection using the command > > "virDomainCoreDumpWithFormat" and the created files appear to belong to > > root (both user and group). > > > > I have searched around but

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >&nbsp;</div> <div dir="ltr" ><div dir="ltr" >Hi,</div> <div dir="ltr" >&nbsp;</div> <div dir="ltr" >I am trying to understand libvirt

On 20. 3. 2020 20:57, Martin Kletzander wrote: > On Fri, Mar 20, 2020 at 03:38:36PM +0000, Joe Muro wrote: >> Hi, >> > > Hi, could you please configure your client to send plaintext version as > well? > We mainly prefer plaintext on this list ;-) > >> I am trying to understand libvirt dynamic ownership behavior. I have a >> VM that >> uses a qcow2

Hi Martin, thanks for the explanation. Now I understand why libvirt doesn't revert the file permissions back to the original. I am running these VMs on an isolated test machine, so I'll disable dynamic file ownership and make sure libvirt has access to image files. Sorry about the message formatting. I modified settings on my client, hopefully it sends plaintext now. (I'll switch to

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

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

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

On 09/20/2018 12: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 >>>

On Wed, Oct 03, 2018 at 01:04:50PM -0300, Rodrigo Siqueira wrote: >Hi, > >My colleagues and I have a set of scripts that we use to automate our >daily tasks related to the Linux Kernel. As a result, most of our code >relies on the QEMU features; and recently we decided use libvirt instead >of QEMU. However, we have some questions, and I would like to know if >someone could

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

Hi The problem is after I successful live migrate a domain, the domain os become read-only. and when I use qemu-img to show the disk info at node which domain current running , the command return 'Permission denied'. BUT, I can use qemu-img show the disk info at the previous node. My Env: two node, all install libvirt + kvm . use glusterfs as shared storage. the libvirt/kvm version:

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

On Fri, May 31, 2013 at 04:03:32PM +0800, Qiu Yu wrote: > Actually I'm looking into an issue with OpenStack / Libvirt manipulating > LVM as an image backend. When the logical volume is created, udev rules > will set the ownership to root:disk. After libvirt actually starting an > instance, device node ownership will change to qemu:qemu by libvirt. Then, > if you stop an

Just a hunch but is the binary that creates the dump suid? You may want to check the perms on it. Not sure if it is libvirtd or some other binary. Sent from my iPhone > On May 29, 2015, at 3:39 AM, NoxDaFox <noxdafox@gmail.com> wrote: > > 2015-05-28 12:04 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>: >> On 28.05.2015 09:29, NoxDaFox wrote: >> > Greetings,