Comment 25 for bug 1637601

Hi Christian Ehrhardt,

> Sorry to realize that only now, but please help me to clarify/avoid these issues?

no problem; sure.

> #1 On a given Xenial install as of today the files are owned by libvirt-qemu:kvm (e.g. pools and images it creates).
> Those files will still be owned by group "kvm", but after the upgrade libvirt/qemu will fail to access properly right?

You're correct. The user permissions can still allow it to work, but it's not really correct.

For Xenial, I'll upload a patch v2 without the group change. That's more conservative, and correct.
For Zesty and later, I believe it's better to keep the change (aligns w/ Debian).

> #2 I see on the xenial diff you remove the groups in postrm. That will leave the files unowned, just with ther numeric gid.
> Is there any reason to do this delgroup/deluser? And if so why not in Zesty?

Yes, but that's only in the 'purge' case, not in 'remove'.
I think that removing the user/group in 'purge' would be correct, but I admit not to know the right rule for this case.
Per your question, and not to change a established behavior in the LTS, it seems better not to make this change. (removed in v2)

The reason to do it is to align with Debian, but is not strictly required.

In Zesty, that is already done, thus no change required.

> #3 despite the other changes you left the --ingroup kvm - I think it is right to leave it,
> but if you go the route of changing it to libvirt-qemu this would need to change as well.

I don't know if the kvm group is important for something else in the virtualization stack, but that is still aligned w/ Debian, so I opted to keep it.
Keeping it in v2 per Debian, you think it's right, and not doing the libvirt-qemu group change.

> Once sorted out Colin might reassign (or a new one :-/) the gid to "kvm" and you could
> implement it as libvirt-qemu:kvm staying compatible with all setups out there already.

Humbly, I believe I have to defer this discussion to the maintainers in Debian/Ubuntu, people who are more experienced in libvirt/qemu, as the changes (libvirt-qemu user/group and kvm group) were introduced in Debian at some point, for some reason, and those might play a role in other components of the libvirt/qemu/kvm stack. Sorry about the uncertainty, but I'm not really a virtualization guy nowadays. :)

> My suggestion would be:
> - stick to libvirt-qemu:kvm
> - do not drop the user/group on postrm
> Do you think that would work for you then?

Agreed. I'll submit those on patch v2.

Thanks for the careful review and suggestions!