Disposable VMs should inherit the netVM from the AppVM which created it

[marmarek]

Reported by marmarek on 28 May 2014 23:54 UTC
https://groups.google.com/d/msg/qubes-users/PR8SZcxicas/UL7qpurFxssJ

Migrated-From: https://wiki.qubes-os.org/ticket/862

[marmarek]

Comment by joanna on 29 May 2014 11:01 UTC
I think we want to move this to R3...

[marmarek]

Comment by joanna on 29 May 2014 11:01 UTC
I think we want to move this to R3...

[marmarek]

Comment by marmarek on 29 May 2014 12:30 UTC
This seems to be very important feature, especially for torvm users (even when workaround exists), so I think we should keep this in R2.1 milestone.

[marmarek]

Comment by marmarek on 29 May 2014 12:30 UTC
This seems to be very important feature, especially for torvm users (even when workaround exists), so I think we should keep this in R2.1 milestone.

[marmarek]

Comment by marmarek on 26 Sep 2014 02:16 UTC
When netvm will be inherited from calling VM, it would be no longer needed to set firewall to "block all" when netvm is set to "none".
The question is: do we want make this the only option, or keep both approaches and let the user choose? Removing the old approach will cleanup the code (that feature is really hacky), but on the other hand, keeping it would be beneficial sometimes. For example for network disconnected DispVMs (PDF converter?).
Or perhaps we want to remove old behavior, and implement it in cleaner way, once #866 done?

[marmarek]

Comment by marmarek on 26 Sep 2014 02:16 UTC
When netvm will be inherited from calling VM, it would be no longer needed to set firewall to "block all" when netvm is set to "none".
The question is: do we want make this the only option, or keep both approaches and let the user choose? Removing the old approach will cleanup the code (that feature is really hacky), but on the other hand, keeping it would be beneficial sometimes. For example for network disconnected DispVMs (PDF converter?).
Or perhaps we want to remove old behavior, and implement it in cleaner way, once #866 done?

[marmarek]

Comment by marmarek on 19 Jan 2015 00:18 UTC
Ok, moving to R3 because that change in R2 code base would be totally different in R3, so don't do the job twice.

[marmarek]

Comment by marmarek on 19 Jan 2015 00:18 UTC
Ok, moving to R3 because that change in R2 code base would be totally different in R3, so don't do the job twice.

[qjoo]

I'm still getting a networked dispvm even after creating it from a offline appvm? (in 3.0-rc1)

[qjoo]

I'm still getting a networked dispvm even after creating it from a offline appvm? (in 3.0-rc1)

[marmarek]

On Sun, May 03, 2015 at 04:22:46AM -0700, qjoo wrote:

I'm still getting a networked dispvm even after creating it from a
offline appvm? (in 3.0-rc1)

Are you sure that the DispVM really have network access? Indeed I see
'eth0' there in such case, but it isn't connected anywhere.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Sun, May 03, 2015 at 04:22:46AM -0700, qjoo wrote:

I'm still getting a networked dispvm even after creating it from a
offline appvm? (in 3.0-rc1)

Are you sure that the DispVM really have network access? Indeed I see
'eth0' there in such case, but it isn't connected anywhere.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?