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

Reply via email to