Suggestions for shared VM hypervisor interoperable with VMWare Workstation on laptops

Hi. I’m trying to improve my team’s virtualisation setup - we all use VMWare Workstation on our Windows laptops to run a bunch of Windows VMs with oddball software packages that can be finicky with hardware changes. At the moment there’s a lot of passing VMs around on USB drives, and getting lost in updated software versions within VMs, or the VM contents drifting from ‘golden image’ milestones.

I’d like to set up a central hypervisor that we can upload VMs from our laptops, so we can get:

  • a canonical ‘known-good’ VM version for each software with snapshotting/clones as software versions are updated in the VM
  • the ability to run up a VM for a quick test without waiting to move them around
  • BACKUPS

But.. the software installed in the VMs can have problems if the hardware changes, so I’m trying to find a way of modifying the virtual hardware as little as possible when uploading or downloading to the server.

VMware Workstation is used on laptops because it’s been the most reliable for USB passthrough, and I don’t like my chances of getting everyone to change the central piece of software they use for work.

Any suggestions for hypervisors or workflows that might smooth the process of shifting VMs back and forth?

1 Like

I might confuse a thing or 2 as I have not used VMware Workstation in years.
So I might think a bit to lightly on this but when you share a VMware virtual machine file it contains the vm image and hardware configuration also right?

What is limiting you from just making a know tested/working VMware virtual machine file available in a tool like git?
I remember there being tools to export and import the hardware config as text from vmware virtual machine images.
So you could even keep track of the specific hardware changes in git.
And when a new change gets committed the others can just import the new config file to their own vm.

As writhing this down I do see the challenges when you push lage vm updates and everyone has to download them.

The funny thing is you are almost describing docker or a distributed container system in your requirements.
I’ll think some more on this tomorrow.

1 Like

You’re correct, unless company policy mandates replacing Vmware Workstation with another piece of software, you’re going to run into resistance when trying to move away from it.

I don’t quite understand the issue you’re trying to solve. From your description, it sounds like each person has their own virtual machine with the company’s approved software, and the problems are coming from people trying to share those individual VMs.

Maybe the better approach is to have a single source of truth, a central host that runs all the virtual machines, and then have each user log into that system instead.

1 Like

Each person has a dozen VMs with different software (or different versions) on each, and half a dozen people might have the same software with their own VM, which may or may not have had updates applied at some point.

The main thing is that we all need to use these VMs when we’re not connected to the company network, so a purely central server solution won’t work. But I need to work out a workflow so that we can all align better with specific VM versions/milestones, rather than the drift from standard setups that we’re seeing at the moment. That’s the reason for interoperability between VMWare Workstation on our laptops and whatever is running on the central server, I was thinking if we can use a central server as a known-good, versioned copy of each VM, then it would provide a workflow that encouraged people to maintain a standardised copy more easily.

A version management tool like git might work for some aspects, I’ll have to look into what would work best with large VM disk files.

I think I’m trying to solve 2 separate problems, and I can see a potential workflow that combines the two, but I’m struggling to find software that will work. The 2 issues are:

  1. A way to run VMs centrally without moving large disk files around for a potentially short usage.
    1. These VMs would be imported from someone’s VMWare Workstation setup, and would be available to run by multiple people in a central location.
  2. A workflow that encourages people to create known-good versioned virtual machines that can be cloned and used by others, giving a reliable method of getting back to a particular software version.

At the moment we all maintain individual copies of VMs and they tend to drift from the version we would like because of people developing in them, or them being repurposed for other projects without duplication.

I was thinking of combining the solutions to both problems so that the live, central VM was versioned/cloned/snapshotted to allow others to use the versioned VM on their local machine. I was combining the solutions in the hopes of getting a workflow that made the simplest method of getting the job done the closest to the ideal, rather than trying to enforce a workflow on people who were just trying to get their job done.

Vmware workstation can connect to an Esxi hypervisor server or to a vCenter server (it could also do that with another vmware workstation in the past but that was too good and they removed it). And run remote VMs on that esxi server as if they were local, showing you the screen and all the usual things.
The only difference is that it won’t have access to the local laptop GPU for rendering so if you are running graphics-intensive software (CAD and whatnot) it may run like garbage.

It can also move or clone VMs from local to server and vice versa.

you can use the user privilege system to corral a bit what the users can do.

Since you are in vmware ecosystem, going with an esxi server is probably the simpler way for the users, since for them it would still be mostly using Vmware Workstation.
The issue of this system is probably cost, since you will need to get a license and pay a subscription even if you already have hardware that can run it.

Other hypervisors support working in a similar way and may be cheaper or better but will require migrating the VMs and retraining the users to use something else.
Microsoft’s Hyperv with hyper-v manager, KVM/Qemu on Linux with virt-manager and gnome boxes and whatever other gui tool usually support remote management and Virtualbox with its own server component that can be accessed by virtualbox clients

1 Like

Why? This is what VPN is for. Your current workflows sound like madness. Seems to me that your lives would be simplified with all the VMs stored centrally, available to be cloned quickly, no more thumb drives… Virtual hardware becomes quite static with everything running centrally. Security would likely be improved as well.

2 Likes

I think ESXi might be the only realistic solution here.

Any suggestions on snapshots/clone workflows to keep versioned milestones for each VM? We do have an external NAS with a 10Gb link if we need to export them outside the ESXi system to get the behaviour we want.

Why? This is what VPN is for.

Being able to work on the VM offline is actually the only part of the potential workflows that’s a firm requirement. We often need to work on customer sites with particular versions of software, and may not have reliable internet access. As mentioned, we also often use USB passthrough on the VMs to interface with local hardware.