Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up'/etc/init.d/qubes_netvm stop' should also stop the netvm #172
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by marmarek on 30 Mar 2011 23:30 UTC
2) Yes, good idea, but... what "stop method"? It didn't exists for now (qvm-run and qubes-manager calls "xm shutdown" directly). And what with shutdown monitor? Should it wait for every VM, or just netvm? In the first case - it have to know what VMs are shutting down.
So I think, the better idea (for the second reason) is to add dependency resolving to qubes.py, but stop depended VMs in qvm-run (and qubes-manager - with warning to the user).
|
Comment by marmarek on 30 Mar 2011 23:30 UTC So I think, the better idea (for the second reason) is to add dependency resolving to qubes.py, but stop depended VMs in qvm-run (and qubes-manager - with warning to the user). |
marmarek
self-assigned this
Mar 8, 2015
marmarek
added this to the Release 1 Beta 1 milestone
Mar 8, 2015
marmarek
added
bug
C: core
P: major
labels
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Comment by marmarek on 31 Mar 2011 00:48 UTC
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 31 Mar 2011 09:00 UTC
Looks good. Except for the get_running_netvms() function that IMHO should be replaced with a proper qvm-* tool, as the xm output might change in the future. Closing for now anyway.
|
Comment by joanna on 31 Mar 2011 09:00 UTC |
marmarek
closed this
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by joanna on 7 Apr 2011 08:29 UTC
First of all I get an exception when I do :
qvm-run --shutdown netvm
Seccond, GUI manager happilly stops the netvm or firewallvm without stopping all the dependent VMs. I think the quick solution is to just remove 'stop' action from the GUI manager. After all if somebody is willing to stop netvm or firewallvm, then we can assume this person can play with command line.
|
Comment by joanna on 7 Apr 2011 08:29 UTC
Seccond, GUI manager happilly stops the netvm or firewallvm without stopping all the dependent VMs. I think the quick solution is to just remove 'stop' action from the GUI manager. After all if somebody is willing to stop netvm or firewallvm, then we can assume this person can play with command line. |
marmarek
reopened this
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 8, 2015
Member
Comment by marmarek on 7 Apr 2011 08:51 UTC
Fixed: http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=e9c6dc387ecb048ef580c701585edffa69062010
Additionaly blocked NetVM (and ProxyVM) stopping in qubes-manager:
http://git.qubes-os.org/gitweb/?p=marmarek/qubes-manager.git;a=commit;h=9a1b06b441768d8cac7367f1a1dbf343c3fcf1b9
|
Comment by marmarek on 7 Apr 2011 08:51 UTC Additionaly blocked NetVM (and ProxyVM) stopping in qubes-manager: |
marmarek commentedMar 8, 2015
Reported by joanna on 30 Mar 2011 22:56 UTC
Currently it only stops the firewallvm, because we currently mark the firewallvm as the default netvm. I think that this script should be changed to:
stop all the netvms in the system (again user might have more than one, e.g. one for each NIC)
also stop all the dependent VM's -- i.e. whenever we stop a netvm or proxyvm, all the vm's that use this vm as netvm should recursively be stopped as well. I think this should be implemented not in the qubes_netvm script, but instead in qubes.py in stop method.
Migrated-From: https://wiki.qubes-os.org/ticket/172