------- Comment From [email protected] 2019-01-23 23:48 EDT------- (In reply to comment #68) > TBH - I haven't taken the former comment as a call for further action. > It was more of a summary how docs and output could be better. > > Let me answer: > > 1. document that --bypass-cache would help > > Yeah it might be nice, but then it is just such a general thing. > It only affects apparmor users (not all libvirt users). > It only affects /tmp wi > I wonder how such a hint might look like. > Checking the doc there is a Note on disk corruption for virsh restore - > maybe there as another Note entry. > But I'm still not all in for this.
Okay, fine. > > 2. on older releases "error out or warn in Libvirt when performing save in > denial paths" > > It is not really possible to predetect and differentiate if such a denial > was the reason. > Looking into the future I think we might use per-guest overrides. > > I was thinking on that more, the fact that all other but /tmp (for the > explicit deny) just work, like: > $ virsh save xenial-testshutdown-0 /var/anythingbuttmp.state > $ virsh restore /var/anythingbuttmp.state > That annoys me a lot. > > I'd suggest otherwise, we keep the past as it is without modifying man pages > or anything like it (after all it is no regression I can SRU and a very > special case choosing /tmp only). > But I want to make it better thinking forward. > I thought about it again and again, and revisited the old bug that added > those deny rules. > I think it is time to take them out in the next release. Agree with you on this. > > That would mean it would generally work, and even if there is a deny it > would at least be in the log. > See also: > - https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1403648/comments/6 > - https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1403648/comments/12 > > I think the old assumptions don't hold true. > So for the current and stable-releases we keep it as is, to not regress > anyone (with too much logs). > But forward I'd drop the deny rules and then all of this (and similar things > where users WANT e.g. images in /tmp) would work. ACK > > Part of it would be to check (way more modern and recent) openstack that it > no more has those issues and if it has as part of the fix look for something > better e.g. adapt how openstack sets the ceph config to no more trigger /tmp > /tmp/var access. > > There are also rules like owner /tmp/pulse-*/ rw, in the meantime which get > trumped by the deny. > TL;DR - taking out the deny and making the save/restore case of this bug no > more a special case would be much better IMHO. > > If you are ok with that I'd create a new bug to: > 1. take out the deny rules to /tmp early in Ubuntu 18.10 Yes, I am okay on it. > 2. do an analysis with recent openstack+ceph if they still trigger access > there well, I am not working on openstack and ceph. so could not comment on it. > > So are you ok with that approach? :+1: for 1 > > P.S. If you really really (...really*) want/need a man page entry for this > special case we could work something out, but I think that would not qualify > as an SRU [1] so thinking forward is much better anyway. As you have mentioned earlier, I think it is not necessary. > > [1]: https://wiki.ubuntu.com/StableReleaseUpdates Thank you for your support. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1719579 Title: [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719579/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
