Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Connecting VMware Workstation guests to the external world

This is just a writeup on what I am doing in my test lab setup. Mainly as a reminder to me.

My host laptop has an interface with a dynamically assigned private IP from my router. This laptop runs VMware Workstation, in which there are a couple of guests.

The easiest option would be to assign a NAT interface to each of these guests. That way they are all on a private network of their own, but with Internet access via VMware NAT.

A note on NAT. What is it? NAT is a way to hide private IP blocks from the outside world. Like in this instance, you don’t want to assign each of your guests public IPs as they are private machines and it’s a waste of public IPs. What you want is to assign these machines a private IP yet ensure they can connect to the outside world. So what you need is for one machine – the host in this case – to be on the Internet via a public IP or private IP (in which case the router that provides the private IP is hiding the host behind it) and all other machines to be hidden behind it.

The way NAT works is that it creates a private IP space on the host. The host is given an IP address from this private space, as are all the guests. The guests use this private IP of the host as their router, and the NAT service on the host receives packets, sends them out to the Internet but changes their source IP to be that of the external IP of the host and keeps note of this, and when it receives packets it reads them to identify which guest it is directed to and passes it on.

In VMware NAT, it is optional to give the host an IP from the private space as the NAT service creates a separate private IP – hidden from the host too, but residing on the host – and the guests use this IP as their router IP. This IP also provides DNS services for the guests. Here’s a screenshot from the network settings page of VMware Workstation.

nat-network

I have defined a virtual network called VMnet1 and assigned it as a NAT network. In this case I chose to have the host too connected to this network – and so my host has a VMnet1 interface with IP address 192.168.126.1 – and my VMs will have DHCP addresses assigned from this pool.

From one of my VMs:

Notice the default gateway is 192.168.126.2 and not 192.168.126.1. Just to confirm they are different interfaces, we can check the MAC address table:

Different MACs. Both virtual adapters (based on the 00-50-56 prefix, which belongs to VMware) but different adapters.

The VMs see the DHCP server too as another virtual adapter on the network. In my case the DHCP addresses are offered from 192.168.126.254 – yet another virtual adapter on the host that’s not visible to the host.

With VMware Workstation, I don’t have to create a separate network for NAT. I could have assigned each interface of the VMs as NAT and that too would do the trick, but creating a separate network has its advantages. I can control the range of IP addresses assigned to the guests, and I can have the host too assigned an interface from this pool. I can also choose the gateway address to be something else – say to be the IP of the host.

(Originally this post was meant to have more details but I got busy with other stuff. Rather than let it go to waste I am publishing it anyways. Hence the abrupt ending).

Suspend and Resume all VMware Workstation VMs

These are two simple scripts. I spent quite a bit of time Googling various things to create it as my batch file days are behind me. The first script suspends all active VMs. The second script resumes all these suspended VMs. The advantage of this over the tray icon to suspend and resume all VMs is that it stores the active VMs (that are getting suspended) in a text file so it’s easy to resume just these active VMs.

Using netsh to set Static/ DHCP addresses

Place where I work, our desktops are locked down so regular users have no access to the network settings. And since I am always logged in as a regular user and only use my admin account via RunAs (because it’s best practice not to be logged in with your admin account) I don’t have access to the network settings window either. Of course I could logout-login, but who does that!?

Enter netsh (or PowerShell if you are on Windows 8, but I am on Windows 7 at work).

To show your currently assigned IPv4 addresses and interfaces:

To set a Static IPv4 address for the “Local Area Connection” interface:

And to set a DHCP IPv4 address for the “Local Area Connection” interface:

Easy peasy! (sort of)

A cool thing about netsh is that it’s an interactive shell so you can type netsh at the command prompt to enter the shell and then navigate around to get a list of commands and slowly figure your way out.

Moving on …

Today I discovered that I am no longer a fan of Linux/ *BSDs (henceforth called just “Linux”) the way I used to be before. That’s a significant event for me as I spent a major part of my younger days as a Linux user and I owe my strong fundamentals of Internet concepts (e.g. DNS, SMTP) to Linux and so it is surprisingly yet not disappointing that I am no longer a fan of it.

Admittedly it’s been a while since I played with Linux. I think I played with it last year to try DNSSEC and Unbound. I still have a Debian virtual server in my network that runs Unbound and provides SAMBA file-sharing for my WDTV Live box, but I barely look at it as *touchwood* it runs without a fuss.

I was a Windows user growing up, and I chose computers because I enjoyed working with Windows. Not necessarily the GUI, mind you, I started with MS-DOS 2.x and using text based tools such as Norton Commander (sigh) so I quite enjoy the command line. When I joined college Solaris (eugh!) and RedHat Linux were used in our labs and so I got hooked on to them soon enough. From there on it was a journey experimenting with various Linux distributions as well as quickly moving on to FreeBSD, OpenBSD, and NetBSD. I enjoyed the *BSDs more than Linux – I still do by the way. The *BSDs had more structure and organization to them and I felt more comfortable working with them.

Most of college was spent working late into the night on Linux and the *BSDs (again henceforth just called “Linux”). Virtualization wasn’t around back then so it was all about multi-booting these various OSes on the one desktop I had. And not just multi-booting – which in itself was a challenge as the *BSDs each use a different partitioning system and boot loaders – but also getting them to see each other’s data as they all used slightly different filesystems. Added to that I had no Internet in the dorm (where my desktop was) so it was mostly down to me trying and getting updates and installation ISOs from our lab and getting them to the dorm somehow. I don’t remember how I used to do it back then, USBs weren’t popular either so I can’t imagine what I used to do.

Once I left college, changed a couple of jobs, and got married I started reducing my time with Linux. The zenith was when I had three physical desktops at my house – named Asterix, Obelix, and Dogmatix – running FreeBSD and hosting my domain email, DNS, and website on a paltry ADSL link. That was dismantled after my daughter was born, I think, and then I moved to virtual servers on the Internet (running Debian on KVM) as well as on my home desktop/ laptop (Debian, KVM, SPICE). But by then I was slowly starting to let go of Linux. For one I wasn’t a fan of the newer GUIs such as Unity, KDE4, and GNOME3, and I was also starting to dislike the “various parts put together” nature of other GUIs such as XFCE and LXDE. I know I was a big fan (and still am) of the Unix philosophy of having various programs that do one thing and doing it well, and then interconnecting these programs together, but somehow that didn’t translate well for me with GUIs. When using a GUI I expect a seamless experience and that wasn’t happening with all these GUIs made up for various parts.

Another reason why I slowly started drifting from Linux is job prospects. I had a lot of Linux experience, but that was mostly as a hobby. Nothing I could show as professional experience, which was mostly in Windows. I suppose if I had been in some other country where there were more Linux users and groups and opportunities, or if I were the sorts who went out and found opportunities for myself by volunteering with open source projects and such, I might have made some head on … but all that never happened and slowly I was working less and less on Linux.

Anyhow, flash forward this past month, I tried FreeBSD (and FreeNAS) a few days ago to check out ZFS and also FreeBSD v10. Today I had tried out pfSense as I wanted a firewall for my virtual environment. Today I had also tried CentOS, and two days ago I had tried Debian. And on all these occasions after installing the OS I didn’t feel that eager to work with it. I knew I could spend some time and configure them, but somehow there wasn’t the excitement any more. And very strangely, with each OS I kept thinking of Windows Server and PowerShell! Which is amazing, because a few years ago I would have never imagined preferring Windows over Linux, but to give credit to Microsoft they have done a brilliant turnaround with Windows and have slowly revamped their server offerings and so I am a huge Windows fan nowadays. I think Server 2012 is a great product (as is Server 2012 R2 which brings subtle refinements). I am very excited by PowerShell and how Microsoft is slowly integrating it more and more into the OS itself. I think it’s pretty cool being able to install Server Core and then configure most of it using PowerShell and with the newer versions of PowerShell in these newer OSes more features are configurable via the command-line.

So I think it’s a mixture of me slowly moving away from Linux but at the same time Windows slowly improving to be an OS I like, that I am no longer a Linux fan. And that’s why it is both surprising but also not disappointing. I am surprised this happened as I never expected to like Windows ever, but I am not disappointed because Windows Server 2012 (as well as Windows 8) are excellent OSes in my opinion and I truly enjoy working with them. (Of course Server Core still has lots of scope to improve, but that’s for later versions I guess).

I don’t want to forget this date as some day in the future I’ll look back and wonder “hmm, what day was it when I realized I am no longer a Linux fan?” and then I can read this blog post and reminisce. It’s also a sort of return to the roots for me as I started with DOS/ Windows and am now returning to PowerShell/ Windows.

DFS namespace empty after reboot

One of our sites had the following issue. It has a Server 2008 R2 DC which was also hosts DFS and whenever the server is rebooted, sometimes the DFS namespace appears empty until the DFS Namespace service is restarted.

I tracked it down to a timing issue.

The DFS namespace was a domain based one. Which means even though the server hosts the namespace root, it doesn’t have any information on the root until AD is up and running. This is because domain based DFS information is stored in AD (unlike stand-alone DFS where the information is stored in the server registry) and so the DFS Namespace service looks to AD for details. Had the DFS server been a separate one it would have contacted the local DC and got this, but in this case the DC and DFS Namespace are on the same server and so it all came down to which service was up first. If AD initialized before DFS, when the Namespace service runs it is able to contact AD and get the info. But if the Namespace initializes before AD, when it contacts AD for info it gets nothing and so assumes there’s no namespaces present. The result is an empty namespace, and the c:\DFSRoots folder (or whatever you have chosen) is empty. If you restart the DFS Namespace service a while later, it is able to contact AD and present the namespace.

The easiest way to see if AD is initialized is via Event Viewer. Go to Custom Views > Server Roles > Active Directory Domain Service. When AD is ready an event ID 1000 is generated from source ActiveDirectory_DomainService that tells you AD startup is complete.

AD initialized

Similarly, to check when DFS initialized go to the Event View, Windows Logs > System. Check for events from source DfsSvc – when DFS has completed initializing an event with ID 14531 is generated.

DFS initialized
When the namespace is empty you’ll see that the time-stamp of the DFS event is before the AD event. In my testing as long as DFS initializes a second before AD is ready the namespaces are fine, but anything longer than that and the namespaces are empty.

There doesn’t seem to be any other fix for this than delay the startup of the DFS Namespace service. Again, only the DFS Namespace service is what matters. Not the DFS Replication service. There are two parts to DFS – one if the namespace, which provides the unified namespace and folders beneath that; other is the replication bit which ensures that if a target points to multiple servers each of these servers are kept in sync. You don’t necessarily have to use the DFS Replication service to keep these replicated – use whatever tool you prefer, DFS Replication is what’s provided in the box for you. If your namespace is missing the DFS Replication service has nothing to do with it. (On the other hand, if your namespace was fine but some of the targets had incorrect data then DFS Replication is what you should focus troubleshooting on).

What I did in this case was set the startup type of DFS Namespace to “Automatic (Delayed Start)”. In my testing, on this particular server, this delayed the startup of the DFS Namespace service by about 3 minutes. AD initializes in about 50-90 seconds so there’s ample time after AD is ready and for other services to launch, before DFS Namespace runs. There is no impact for users too as there are multiple namespace servers – all of them being in different sites in this situation – and so if users were to connect to DFS in the 3 minute period after a server reboot they would connect to one of these different namespace servers. Yes, there will be a bit of a delay as they are connecting to an off-site server, but when they access any target after that they will be sent back to the local site (provided there are target servers there) and so there’s no performance impact.

If the 3 minute window too is unacceptable I suppose one could set the DFS Namespace service to manual start and use the Task Scheduler to start it manually after a few seconds after reboot.

Hope this helps anyone else.