libvirt users - Feb 2023 - Unable to set XATTR trusted.libvirt.security.dac Operation not supported

On 2/2/23 20:05, Simon Fairweather wrote:
> Running with Kernel 6.1.8?
> 
> QEMU 7.1 libvirt 8.7
> 
> setting remeber_owner = 0 resolves the issue but was working ok on
> kernel 6.0.x.
> 
> root at computenode:~# cat ?/etc/libvirt/qemu.conf | grep reme
> # Whether libvirt should remember and restore the original
> remember_owner = 0
> root at computenode:~#?
> 
> Any known issues for this, is it likely to be QEMU/KVM?
So is there a failure you're seeing (e.g. a domain unable to start) or
is this just a warning printed into logs?

Can you shed more light into what path is libvirt unable to set XATTRs
on and what's the underlying filesystem?

Michal

Thanks Michal, following your suggestion on FS It looks like a fuse 3.13.0
issue, if I use drive mount point it works. Should have checked this first.

Error was on VM start and would not let it start.

Regards
Simon.

On Mon, Feb 6, 2023 at 9:20 AM Michal Pr?vozn?k <mprivozn at redhat.com>
wrote:
> On 2/2/23 20:05, Simon Fairweather wrote:
> > Running with Kernel 6.1.8
> >
> > QEMU 7.1 libvirt 8.7
> >
> > setting remeber_owner = 0 resolves the issue but was working ok on
> > kernel 6.0.x.
> >
> > root at computenode:~# cat  /etc/libvirt/qemu.conf | grep reme
> > # Whether libvirt should remember and restore the original
> > remember_owner = 0
> > root at computenode:~#
> >
> > Any known issues for this, is it likely to be QEMU/KVM?
>
> So is there a failure you're seeing (e.g. a domain unable to start) or
> is this just a warning printed into logs?
>
> Can you shed more light into what path is libvirt unable to set XATTRs
> on and what's the underlying filesystem?
>
> Michal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20230206/58662097/attachment.htm>