On Fri, Jun 14, 2019 at 7:05 PM Milan Zamazal <[email protected]> wrote:

> Alex McWhirter <[email protected]> writes:
>
> > In this case, i should be able to edit /etc/libvirtd/qemu.conf on all
> > the nodes to disable dynamic ownership as a temporary measure until
> > this is patched for libgfapi?
>
> No, other devices might have permission problems in such a case.
>

I wonder how libvirt can change the permissions for devices it does not
know about?

When using libgfapi, we pass libivrt:

            <disk name='vda' snapshot='external' type='network'>
                <source protocol='gluster'
                        name='volume/11111111-1111-1111-1111-111111111111'
                        type='network'>
                    <host name="brick1.example.com" port="49152"
                        transport="tcp"/>
                    <host name="brick2.example.com" port="49153"
                        transport="tcp"/>
                </source>
            </disk>

So libvirt does not have the path to the file, and it cannot change the
permissions.

Alex, can you reproduce this flow and attach vdsm and engine logs from all
hosts
to the bug?

Nir

> On 2019-06-13 10:37, Milan Zamazal wrote:
> >> Shani Leviim <[email protected]> writes:
> >>
> >>> Hi,
> >>> It seems that you hit this bug:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1666795
> >>>
> >>> Adding +Milan Zamazal <[email protected]>, Can you please confirm?
> >>
> >> There may still be problems when using GlusterFS with libgfapi:
> >> https://bugzilla.redhat.com/1719789.
> >>
> >> What's your Vdsm version and which kind of storage do you use?
> >>
> >>> *Regards,*
> >>>
> >>> *Shani Leviim*
> >>>
> >>>
> >>> On Thu, Jun 13, 2019 at 12:18 PM Alex McWhirter <[email protected]>
> >>> wrote:
> >>>
> >>>> after upgrading from 4.2 to 4.3, after a vm live migrates it's disk
> >>>> images are become owned by root:root. Live migration succeeds and
> >>>> the vm
> >>>> stays up, but after shutting down the VM from this point, starting
> >>>> it up
> >>>> again will cause it to fail. At this point i have to go in and change
> >>>> the permissions back to vdsm:kvm on the images, and the VM will boot
> >>>> again.
> >>>> _______________________________________________
> >>>> Users mailing list -- [email protected]
> >>>> To unsubscribe send an email to [email protected]
> >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> >>>> oVirt Code of Conduct:
> >>>> https://www.ovirt.org/community/about/community-guidelines/
> >>>> List Archives:
> >>>>
> https://lists.ovirt.org/archives/list/[email protected]/message/TSWRTC2E7XZSGSLA7NC5YGP7BIWQKMM3/
> >>>>
> _______________________________________________
> Users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/[email protected]/message/36Z6BB5NGYEEFMPRTDYKFJVVBPZFUCBL/
>
_______________________________________________
Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/[email protected]/message/AKENVDWK3VE3COWVPWWYVJBQC2CIEAAY/

Reply via email to