There are a few instances where you want to run SQL Server on macOS and interact with it from a windows VM. As someone that works within the world of SQL Server/Azure SQL, the use of SQL Server Management Studio (SSMS) comes to mind immediately - for the tasks you can’t complete in Azure Data Studio on macOS directly. Another adjacent (and generally unfortunate scenario) is when work with .NET Framework is required, and for that, you need Windows. This article will step through the network information needed to connect from a Windows VM on macOS to a SQL Server container.

A few basics

I want to rehash a few things quickly as to why we have this specific setup - a macOS host machine running both a container runtime (Docker) and Parallels for VM hosting. The arm64 CPU architecture of modern macOS machines as part of their SoC (system on a chip) hardware is just about magical (not a technical term) compared to a lot of other contemporary machines, especially factoring in the power sipping consumption, but a number of components are not natively available. SQL Server, for example, is only available as an x64 installer for Windows/Linux and an x64 container.

Operating systems are able to offer integrated emulation layers, such that they can run applications that don’t match their CPU architecture. For example, Windows on arm64 can run the x64 SQL Server Management Studio with a slight performance hit due to the emulation layer. On macOS, the emulation layer is able to interact with the Docker container runtime and run containers built for x64.

Your best bet for running a Windows VM on macOS is to run an arm64 image of Windows in Parallels, and within the VM you can run the Windows applications you need - except SQL Server itself.

VM networking

Shared networking is the recommended (and default) network setting in Parallels. In this network layout, your macOS machine is automatically sharing its network connection with the VM and this is usually sufficient for VM use. The other insight we need to connect between macOS and the Windows VM is knowledge of the virtual subnet (network) between the macOS host and the VM.

The fastest way I’ve found to get my network info for the VM is within the VM itself, using ipconfig from Windows terminal. From its output, I note the VM’s IP address and its gateway address. On my machine, the VM has the address 10.211.55.3 and the gateway is 10.211.55.1.

Conceptually, our macOS machine is playing 2 roles in the VM network - both the gateway and as a participant in the network. The SQL Server container running on our macOS host is available to the Windows VM at the IP address assigned to our host as a participant in the network.

Since the gateway address is x.x.x.1 and the VM is assigned x.x.x.3, I’m going to made an educated guess that my host machine is available at x.x.x.2. All that IP address information I gathered by running ipconfig from the Windows VM.

Test the connection

Using any SQL client application on the Windows VM will allow me to test the connectivity to the SQL container. This moment is a good one to fire up SSMS in the VM. I’ll use the address 10.211.55.2 as my SQL server address.

If you encounter difficulties gaining connectivity, you may need to adjust firewall settings in macOS. If your firewall is enabled, use the Options button to allow specific connections.

Recap

While there’s a lot of the development process that you can accomplish from just about any machine, there are still some specific instances where you need that Windows VM. With the default shared network setting, your macOS host has an address assigned to it that you can determine and use to connect from the Windows VM to a container running on macOS. In the setup on my machine, the Windows VM was assigned 10.211.55.3 and the macOS host (and SQL Server container) was available at 10.211.55.2.