Re: [qubes-users] Possibility to detect suspend events in VM?
Am 12.07.20 um 14:37 schrieb unman: > On Fri, Jul 10, 2020 at 01:04:40PM +0200, Phil Kn??fer wrote: >> Hi, >> >> when accessing an SMB share in a Qubes AppVM after the system has been >> suspended for some time, I experience a serious lag (up to about a >> minute or so for each share that is mounted from the same SMB server). >> This seems to be due to the fact that the server has already timed out >> the SMB session, while the client (the AppVM) is still trying to resume >> it and therefore runs in TCP timeouts. >> >> For bare-metal Linux systems, a possible solution is to unmount all SMB >> shares before the system goes into suspend (e.g., via a script in >> /usr/lib/systemd/system-sleep or via pm-utils). >> >> I tried this approach in Qubes but it seems that the AppVMs do not know >> about a suspend event. Is there a way to trigger scripts on suspend in >> Qubes AppVMs or do I need to coordinate the SMB unmount from dom0 (it >> should be possible to trigger a script there that interacts with VMs via >> qvm-run or similar)? >> >> >> Regards, >> Phil >> >> > I think that the dom0 route is the way to go - it's what I use myself. > If you did find a way in the qube of detecting such events, I'd be > interested. I just had the time to look into this. Analyzing journalctl in an AppVM I saw the line: Jul 22 18:45:04 work qrexec-agent[6750]: executed root:QUBESRPC qubes.SuspendPreAll dom0 pid 6753 A quick web search yielded this Github issue: https://github.com/QubesOS/qubes-issues/issues/1663 TL;DR: I haven't tested it yet but it seems placing the PRE- and POST-suspend files in /etc/qubes/suspend-pre.d/ and /etc/qubes/suspend-post.d/ should do the trick. Regards, Phil -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1ede7803-20d4-f93b-a3fa-0f441ca61c7c%40digitrace.de.
Re: [qubes-users] Possibility to detect suspend events in VM?
On Fri, Jul 10, 2020 at 01:04:40PM +0200, Phil Kn??fer wrote: > Hi, > > when accessing an SMB share in a Qubes AppVM after the system has been > suspended for some time, I experience a serious lag (up to about a > minute or so for each share that is mounted from the same SMB server). > This seems to be due to the fact that the server has already timed out > the SMB session, while the client (the AppVM) is still trying to resume > it and therefore runs in TCP timeouts. > > For bare-metal Linux systems, a possible solution is to unmount all SMB > shares before the system goes into suspend (e.g., via a script in > /usr/lib/systemd/system-sleep or via pm-utils). > > I tried this approach in Qubes but it seems that the AppVMs do not know > about a suspend event. Is there a way to trigger scripts on suspend in > Qubes AppVMs or do I need to coordinate the SMB unmount from dom0 (it > should be possible to trigger a script there that interacts with VMs via > qvm-run or similar)? > > > Regards, > Phil > > I think that the dom0 route is the way to go - it's what I use myself. If you did find a way in the qube of detecting such events, I'd be interested. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200712123719.GE922%40thirdeyesecurity.org.
[qubes-users] Possibility to detect suspend events in VM?
Hi, when accessing an SMB share in a Qubes AppVM after the system has been suspended for some time, I experience a serious lag (up to about a minute or so for each share that is mounted from the same SMB server). This seems to be due to the fact that the server has already timed out the SMB session, while the client (the AppVM) is still trying to resume it and therefore runs in TCP timeouts. For bare-metal Linux systems, a possible solution is to unmount all SMB shares before the system goes into suspend (e.g., via a script in /usr/lib/systemd/system-sleep or via pm-utils). I tried this approach in Qubes but it seems that the AppVMs do not know about a suspend event. Is there a way to trigger scripts on suspend in Qubes AppVMs or do I need to coordinate the SMB unmount from dom0 (it should be possible to trigger a script there that interacts with VMs via qvm-run or similar)? Regards, Phil -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/25163aff-4477-ed58-509d-351b6bcfbd97%40digitrace.de.
