Because I always forget stuff like this
I have a confession to make, dear readers:
I am a horrible VM admin.
I’m also not great at networking.
When I go to set up a VM to do something like install SQL vNext, I want to be able to talk to it.
Why bother?
Well, SSMS is no longer part of the SQL install. I don’t really want to copy another 800 MB file over to my VM and install it.
I’m also a devoted fan of Red Gate’s SQL Prompt, because I’m lazy and forgetful. I only have the one license, and I do my very best to respect that by not installing it (even temporarily) in more than one place.
And, you know, I should also probably practice what I preach about not RDPing into a server and running SSMS. That’s not very nice. Not very nice at all.
ICU TCP
So how does one get SSMS connectivity between a Hyper-V host and guest?
The magic of magic numbers. And by magic numbers, I mean IP addresses.
In your Hyper-V Manager, click on the Virtual Switch Manager
You’ll want to create an Internal network
Next, in your VM guest settings, you’ll want to assign it to use the internal network.
Now, on your host, head on into the Networking Control Panel where your connections are listed. You should have a new one for the Internal network you created in Hyper-V
Get the properties of that adapter, and go into the IPV4 properties. I set mine to a generic subnet, and a random 192.168.X.X IP address. Just be careful here if you have hard coded IPs sitting around somewhere.
Now when you start up your VM guest, you’ll want to repeat those steps and assign it the same subnet and a different random IP address.
Et Voila
You may have to kill Windows Firewall, or add in the appropriate exceptions on your Guest and Host to get things working in both directions. But this should be the end of it, and now you should be able to connect SSMS directly to your Guest from your Host.
Thanks for reading!
11 Comments. Leave new
I default my firewall rules from http://smooth1.co.uk/installs/dbinstalls.html#3.1.2 Also find it easier to have a domain controller and use domain accounts rather than keep using either sql logins or runas /netonly or Credentials Manager. Just remember to start the Domain Controller VM before the SQL Server VM!
I do that for more complicated setups in my HA/DR lab, but for one off VMs like this I’m fine with simplicity.
Thanks for posting that link! That is very helpful.
You can also set the VM to use the External network and utilize DHCP, so it gets an address on the network the same way the host does, then you should be able to connect by name easily. The only downside to this is if your machine was off-network for some reason, or if you switch between wired and wireless connections (you just reconfigure the virtual switch to use the appropriate adapter)
I like to keep it internal so Developer Edition can’t phone home ;^}
Personally I prefer VM Box for lab work. The networking is much easier/light weight and (and this is the HUGE ONE), it looks different enough from prod that I don’t worry about confusing prod from my lab and shutting down the wrong one (cauz that would be a bad day)
John – totally understood, but I’d argue that if you use the same virtualization technology at home and at work, you’ll grow your valuable skills faster. (Not saying either approach is right, just putting that out there.)
Thank you for this!
SQL Prompt is licensed on a per user basis so you are able to install it on multiple computers provided that you’re the only user.
(http://www.red-gate.com/assets/purchase/assets/license.pdf)
Steve – in theory, yeah. In practice, they have a key thing that maxes out at a certain number of installs, and it’s a little painful to manage.
Thank you! This is exactly what I needed. Worked the very first time.
Only thing I had to do in addition to this was share the drives I wanted to access and adjust the permissions so the host could write to the virtual drives.