New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'/etc/init.d/qubes_netvm stop' should also stop the netvm #172

Closed
marmarek opened this Issue Mar 8, 2015 · 5 comments

Comments

Projects
None yet
1 participant
@marmarek
Member

marmarek commented Mar 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:

  1. stop all the netvms in the system (again user might have more than one, e.g. one for each NIC)

  2. 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

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

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).

Member

marmarek commented Mar 8, 2015

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).

@marmarek marmarek self-assigned this Mar 8, 2015

@marmarek marmarek added this to the Release 1 Beta 1 milestone Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
Member

marmarek commented Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

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.

Member

marmarek commented Mar 8, 2015

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.

@marmarek marmarek closed this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

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.

Member

marmarek commented Mar 8, 2015

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.

@marmarek marmarek reopened this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment

@marmarek marmarek closed this Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment