Category: VMWare

Short thoughts on Project Nautilus (VMWare Fusion tech preview)

I’m going to be installing this puppy tonight I think. After reading the VMware blog on it here I do have concerns/questions about some of the things it brings to the table.

First, containers are going to be running in their own “PodVM” or pod, which is going to create all sorts of confusion when they bring Kubernetes to the table (as the article says they are going to do), as in K8s “pods” refer to one or a group of containers that are instantiated together and run as an application on a single host.  So in that case, a pod would be a group of containers that run in their own…pods.  I strongly suggest that the really smart folks at VMware find a different name for this construct, even though all the cool ones may already be taken. (“LiteVM”, maybe? “MiniVM”? or just “space”?)

Second- they’ve done something interesting with networking here. In Docker, if you want your container to talk to the network, you need to portmap the container to the localhost, hostport:containerport. This needs to be explicitly stated when you start your container.

With Nautilus, when you start your container, it gets automatically added to a VMnet- so out of the box you’ll get an IP on the NAT’d network so your local machine can get to the container- WITHOUT any explicit exposure/mapping of ports- everything looks like it’s open on that IP address that’s no longer the localhost.  If you add it to a bridged network, the LAN will give the container an IP via DHCP, and any listening ports will be available.   (If I’m wrong here, I’ll correct this ASAP).

Now, one of the things I REALLY like about apps being deployed on K8s is that you’re FORCED to explicitly state what ports the container will allowed to communicate on. This dramatically reduces attack surface and forces the developers and engineers to be much more aware of how their apps are using network resources. I’m sure (hoping) there will be other ways of locking down the containers that get IP’s from the VMnets, but as it looks like they won’t by default, I’m fearful that the quick and dirty way will lead to less security.

I’m looking forward to playing with this, in particular seeing how it works with things like PVCs, and other pipeline, testing, and integration toolsets.  I know it’s just the desktop version and it’s VERY new, but I have a hunch that at least some of the lessons learned are going to end up in Pacific.

VMWare Workstation – DUP! packet issue resolved…sort of

I was getting VERY frustrated with some networking issues with my virtual guests in VMW 15.5 (and prior), on Windows 10.  See below:

dup-packets.png

If you look, you’ll see that for every ping request I’m sending to my gateway (or ANY other IP address outside the Windows host), I’m getting FOUR RESPONSES. This also manifests itself in *very* slow downloads for packages or updates I’m installing on the VM’s.  And, it’s just wrong so it needed fixing.

Note that the standard Google answer to this issue is to stop and delete the Routing and Remote Access Service.  The first time this happened, this solved the problem! There were a ton of other ‘solutions’ out there but none really understood the problem. Windows was creating some sort of packet amplification. (When I have time I’m going to reinstall pcap and dig into this).

But then….months later….

It came back.  I hadn’t re-enabled routing and remote access. I hadn’t made any networking changes inside the host or on my network.   I HAD done some other stuff, such as enabling Windows Services for Linux and installing Ubuntu for bash scripting purposes.  You know…messing around. Some of this could’ve re-written the bindings and orders of networks/protocols/services etc., but if so, it wasn’t reflected anywhere in the basic or advanced network settings. VERY frustrating!

I deleted a TON of stuff I’d installed that I no longer needed (which had to be done anyway, but I was saving that for New Years’). I re-installed the VMware bridge protocol. I repaired VMware Workstation. I REMOVED and re-installed VMware Workstation.

**Here’s what finally RE-solved the problem:

  • I RE-ENABLED RRAS (!)
  • I went into the properties of “Incoming Connections” in Network Adapter Settings and UNCHECKED IPv4, leaving IPv6 checked. (I’m not sure if this matters, try it without this step first).
  • I RE-DISABLED RRAS (!)

And…here’s the result.

non-dup-packets.png

I can only surmise that the act of STOPPING RRAS does a config of the network stack where it doesn’t amplify packets. And, you can’t stop a service unless it’s already started, right?

Makes complete sense.

NOT.

But, all’s well that ends.