Network config is not transferred into container about opengcs HOT 14 CLOSED

I dont think it is a Go issue, network namespaces should be ok in Go. However, I don't believe network configuration is transferred when interfaces are moved into a new namespace (as the config belongs to the other network stack) so you always need to configure after moving to the new namespace.

from opengcs.

My reading of the code is that, eth0 get's configured in the root namespace via configureNetworkAdapter() and that works fine from my logging. @justincormack you are right in that the current config gets lost when the adapter is moved into the new namespace, but moveAdapterIntoNamespace() gathers the current configuration of eth0, moves the interface into the new namespace, and then re-applies the configuration in the new namespace.

The article linked in the OP seems to suggest that, even if one does a runtime.LockOSThread()(as suggested in the netns package, it's still possible, if blocking system calls are executed, the code get executed afterwards on a different thread which is not in the new namespace. libnetwork also seems to bend over backwards to re-exec in some case to execute some code in the new namespace.

from opengcs.

Oh I see. Yes in that case it will be an issue, yes. Starting another process is easiest then.

from opengcs.

@beweedon

from opengcs.

FYI, I have been working on a fix, it compiles, now I need test :)

https://github.com/rn/opengcs/tree/net

from opengcs.

Thanks for root causing this bug! That's a really interesting (and annoying in this case) quirk of the Go runtime. Let me know if you need any help with the fix! I'd be happy to look it over at any point during development!

from opengcs.

I've force pushed an update. I was able to test the new binary manually on a standard Linux system (with a veth pair) and it works without a problem.

However, the integration with gcs does not work and I get an error when trying to run, but there is no meaningful error in the daemon logs. Is there way of getting at /tmp/gcs.log? The utility VM is already gone, so hcsdiag is of no help...

from opengcs.

Try setting this key to the given value (value 1). It should keep the utility VM alive even on error.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\Debug]
"PreserveVmOnErrorDestruct"=dword:00000001

from opengcs.

@beweedon I tried:

$regPath="HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\Debug\"
New-Item -Path $regPath -Force
New-ItemProperty -Path $regPath -Name PreserveVmOnErrorDestruct -PropertyType DWORD -Value 1

And the VM does not stick around. I've also rebooted, just to make sure. I'm on insider build: 16241.1001. Any idea?

from opengcs.

Oh, ugh, that registry key might not work in this case. Do you have the ability to attach WinDbg and break on C++ errors (Debug > Event Filters, then set C++ EH to enabled)? This should break in before the VM is destructed.

from opengcs.

It's been two years since I last used windbg and that was for remote kernel/driver debug. I may need some more details...but generally yes

from opengcs.

NM thanks to a colleague I managed to get windbg to work and got an intriguing error. debugging

from opengcs.

Ah, it turns out there was an additional issue with the code, namely the netlink Link object may change after the interface was moved to the new namespace in https://github.com/Microsoft/opengcs/blob/master/service/gcs/core/gcs/networking.go#L208

Interfaces are indexed by number and numbers are namespaced too. With a very simple setup you may get lucky that eth0 happens to be index 2 in both the root namespace and the new container namespace. With the LinuxKit kernel that was not the case so we gathered all the info for, say eth0 and then tried to re-apply them to a different interface once the namespace was entered.

from opengcs.

Thanks so much for figuring out this problem! I'm reviewing your changes now!

from opengcs.