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. 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. 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. 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 2. do an analysis with recent openstack+ceph if they still trigger access there So are you ok with that approach? 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. [1]: https://wiki.ubuntu.com/StableReleaseUpdates -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in 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 Status in The Ubuntu-power-systems project: Fix Released Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Fix Released Bug description: == Comment: #1 - SEETEENA THOUFEEK <sthou...@in.ibm.com> - 2017-01-17 00:09:16 == Bala, Please mail me the machine information. == Comment: #3 - SEETEENA THOUFEEK <sthou...@in.ibm.com> - 2017-01-17 02:14:06 == 2017-01-16 12:09:37.707+0000: 7024: info : virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on '/var/tmp/bala' 2017-01-16 12:09:37.707+0000: 7024: info : virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on '/var/tmp/bala' to '0:0' 2017-01-16 12:09:37.707+0000: 7024: warning : qemuDomainSaveImageStartVM:6750 : failed to restore save state label on /var/tmp/bala 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+0000: 7024: debug : qemuDomainObjEndAsyncJob:1848 : Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala) 2017-01-16 12:09:37.707+0000: 7024: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca535c0 2017-01-16 12:09:37.707+0000: 7024: debug : virThreadJobClear:121 : Thread 7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with ret=-1 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+0000: 7024: debug : virNetServerProgramSendError:153 : prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590 rerr=0x3fffa59be3c0 2017-01-16 12:09:37.707+0000: 7024: debug : virNetMessageEncodePayload:376 : Encode length as 172 2017-01-16 12:09:37.707+0000: 7024: debug : virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172 offset=0 2017-01-16 12:09:37.707+0000: 7024: info : virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1 serial=4 2017-01-16 12:09:37.707+0000: 7024: debug : virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670 tx=0x100133d2590 2017-01-16 12:09:37.707+0000: 7024: debug : virNetServerClientCalculateHandleMode:192 : mode=3 2017-01-16 12:09:37.707+0000: 7024: info : virEventPollUpdateHandle:152 : EVENT_POLL_UPDATE_HANDLE: watch=417 events=3 2017-01-16 12:09:37.707+0000: 7024: debug : virEventPollInterruptLocked:727 : Interrupting 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133caea0 2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133d23c0 . 2017-01-16 12:14:28.445+0000: 7019: info : qemuMonitorJSONIOProcessLine:201 : QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds": 1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status": "failed"}} 2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcessEvent:147 : mon=0x3fff94004d90 obj=0x100133b5670 2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToString:1762 : object=0x100133a8000 2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133a8000 type=0 gen=0x100133d1160 2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133d2a80 type=2 gen=0x100133d1160 2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToString:1795 : result={"status":"failed"} 2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorEmitEvent:1218 : mon=0x3fff94004d90 event=MIGRATION 2017-01-16 12:14:28.445+0000: 7019: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+0000: 7019: debug : qemuProcessHandleEvent:629 : vm=0x3fff4ca535c0 2017-01-16 12:14:28.445+0000: 7019: info : virObjectNew:202 : OBJECT_NEW: obj=0x100133d2870 classname=virDomainQemuMonitorEvent 2017-01-16 12:14:28.445+0000: 7019: debug : virObjectEventNew:645 : obj=0x100133d2870 2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133d2870 2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:261 : OBJECT_DISPOSE: obj=0x100133d2870 2017-01-16 12:14:28.445+0000: 7019: debug : virDomainQemuMonitorEventDispose:477 : obj=0x100133d2870 2017-01-16 12:14:28.445+0000: 7019: debug : virObjectEventDispose:121 : obj=0x100133d2870 2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcessEvent:172 : handle MIGRATION handler=0x3fff9d7247e0 data=0x100133a8000 2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorEmitMigrationStatus:1488 : mon=0x3fff94004d90, status=failed 2017-01-16 12:14:28.445+0000: 7019: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+0000: 7019: debug : qemuProcessHandleMigrationStatus:1502 : Migration of domain 0x3fff4ca535c0 virt-tests-vm1-bala changed state to failed 2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcess:255 : Total used 232 bytes out of 232 available in buffer 2017-01-16 12:14:28.445+0000: 7019: info : virEventPollUpdateHandle:152 : EVENT_POLL_UPDATE_HANDLE: watch=430 events=13 2017-01-16 12:14:28.445+0000: 7023: error : qemuMigrationCheckJobStatus:2641 : operation failed: job: unexpectedly failed this is an apparmor issue and there is no libvirt bug here. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp