Using Virtual Machines Part 1

My friend Peter Davis recently asked if I could do a blog post how we use virtual machines (VMs) for LabVIEW development. Before I go into too much detail, I do want to say that I learned a lot of what I know about VMs from John Giannangeli of Bolder Software. He did a presentation, probably 2 years ago now, at ALARM. It is worth checking out.

This is the first part of a 2 article series. Here is a link to part 2. This first article is about why one should consider using virtual machines for LabVIEW Development. Part 2 will talk about the details about how we use VMs for development here at System Automation Solutions.

What are virtual machines?

A virtual machine is basically an emulator. It is a computer program that emulates an entire pc. It allows you to run one PC inside another. You have your host system, which is the physical PC. You have a virtualization program running on that which does the emulation. The virtualization software gives the guest operating system the illusion that it is actually running on its own seperate PC. A common reason people do this is to run multiple Operating Systems on the same PC. For example Mac users quite often use this solution for running Windows, so they can access programs that aren’t available for Mac.

Why use virtual machines?

The first thing to understand is why anyone would bother using virtual machines in the first place? Creating and maintaining virtual machines takes some time and effort, so before making that investment it is worth understanding what you are trying to achieve. There are several reasons to use virtual machines for LabVIEW development.

1.  Cutting the ties with Windows

Even though there are LabVIEW versions for Mac and Linux, unfortunately, most LabVIEW work is still done on Windows. Personally, I prefer Linux and when I go to NI Week and the CLA Summit, I see a lot of people with Macs. With a virtual machine, you can have a computer that normally runs OSX or Linux and just switch to Windows when you need to write some LabVIEW code. A virtual machine gives you the freedom to use any computer you want to write LabVIEW code, regardless of what operating system it runs.

2.  Avoiding complications due to multiple LabVIEW versions

If you work on multiple projects, particularly if you support older legacy projects, you will likely have a need to work in multiple versions of LabVIEW. You probably started with one version of LabVIEW and simply installed that on your development machine and all was fine until you had a need for a second version. Your first inclination is probably to simply install the new version of LabVIEW right alongside the existing version. However, that is going to introduce some subtle problems.

When you install a program such as Microsoft Word, if there is an existing version it is removed and replaced with the new version. From that point on any document you open is opened with the new version. With LabVIEW, things are a little different. NI doesn’t want to force you to upgrade legacy code, so the new version is installed alongside the existing version. The way in which Windows determines which version to use will cause problems when double clicking on LabVIEW file (vi, ctl, lvlib, lvproj, etc) in the Windows File Explorer.

What you probably want when you double-click on a vi is to open it with the last version it was saved in. However, Windows simply opens it in the last version of LabVIEW that was used on that computer. If that LabVIEW version is older than the file, then it can’t be opened and you get an error message. This is annoying but benign.

The real problems occur when the LabVIEW version is newer and LabVIEW tries to be nice and automatically updates your code to the newer version. However, it doesn’t give you any indication that it has done so. If you aren’t paying attention (all the new editors look very similar) and edit your code and save it, now you have unwittingly updated your code to a new LabVIEW version. Going back is not always easy. If you are using source code control you could roll it back, but you would lose your changes.  You could also save for previous, but that is tedious. It’s better to avoid this situation.

If this is the only issue you are having, you may not need virtual machines. There are some simpler solutions out there. One of those is AVM.

3.  Managing Driver Versions, Conflicts, and Traceability

Driver Versions are the main reasons that we at SAS use virtual machines for LabVIEW development.  Every project we work on has different driver requirements. Installing and uninstalling drivers when you switch from one project to another is a pain and error prone.

Often drivers are incompatible between projects. Sometimes it is really subtle. For example project A and B may use different versions of a particular 3rd party driver. Both projects may compile and build with either version (ie. the APIs are compatible), yet when you deploy it the hardware may complain or not work without the correct version.

Also if you work in a regulated industry, traceability (keeping track of driver versions) is really important. The easiest way to do that is to have a virtual machine for each project configured with the correct drivers.

4.  Matching System Specifications

Chances are that you do your development on a different machine than you deploy to. I do most of my development on a workstation with a quad-core Xeon processor and 64GB of RAM.  It’s superfast.  Anything I write on it is highly performant. Most of our deployed systems don’t have anywhere near as much processing power or RAM. How do I know my code will work on a PXI chassis with a dual-core core Celeron and 2 GBs of RAM? With a VM, I can specify the number of cores and the RAM to make my development environment more closely resemble the deployment environment. It’s not perfect, but it gives me a good indication of if I’m going to run into problems.

Conclusion

As you can see, if you work on multiple projects, VMs can be a useful way to manage the differences in LabVIEW versions, drivers, and hardware between projects.  Part 2 of this article will describe the tools and processes that we use to create and manage virtual machines.

This is the first part of a 2 article series.  Continue to part 2.

5 Comments on “Using Virtual Machines Part 1

  1. Hi Sam, thank you for sharing. I am really interested in the 2nd part, I hope the managing VM part covers how you keep the installed Windows versions up to date.

    • That is certainly a struggle. Oftentimes when I haven’t opened a VM in a while, like when I revisit an old project, I end up waiting a while for Windows to update. One thought I’ve had (that I haven’t implemented yet) is that there is a Command Line Interface for VMware. You can use that to programmatically launch a VM and run a script inside of it. Perhaps it is worth writing a script that runs periodically (perhaps after every 2nd Tuesday or whatever Microsoft’s schedule is). I would have to do more research. Right now I have a script that runs regularly that defrags and compresses all the virtual disks, I have been thinking about adding code to that to use the CLI to run CCleaner and/or Windows disk cleanup inside the VM first. Maybe I add a line to that script to run the updater as well. Anyone else use the CLI to run scripts inside VMs? I feel like this is getting into the sysadmin/IT world. Oh and in case you didnt know if you run Windows disk cleanup, click on the cleanup system files button. It will let you wipe out all the stuff its downloaded while adding updates (it can be several gig).

  2. How do you handle licensing (NI software & Windows)? As far as I know, you will need a “concurrent” license type if you need to install NI software on more than three machines, right? I definitely see a benefit of using VMs and I’m already using this technology. However, if I’d like to have more than three VM’s, I’d have to upgrade to a concurrent license which is far more expensive than a non-concurrent license.

    • That’s a very good question. I go into this a little more in the second article, which should come out soon. I certainly cannot speak officially for NI, but in unofficial talks with key people, I was given the impression that (under the standard licensing scheme) as long as all of the virtual machines are licensed to the same person and used by only that person and they only use one at time, NI doesn’t seem to care. If you really cared about it, you could install LabVIEW on all your virtual machines unlicensed and then just activate it as soon as you start using it and then deactivate it when you are done. That just seems like jumping through a lot of hoops without benefiting anyone or adding any value. That is for development. As far as using VMs for continuous integration, I was just told recently that they have a seperate license for that. I haven’t looked into that too far. Continous Integration is certainly something I am looking at, but its a little ways away for me. As far as Windows, it depends on what licensing agreement you have with Microsoft. Do you have a single seat, an enterprise agreement, are you an MSDN member, etc. I’m not a lawyer, so I don’t really want to comment on the legality of any of it. I can just tell you what works. There is method of cloning VMs using VMWare in such a way that is doesn’t trip up the Windows relicensing process. I will talk more about that in the next article.

Leave a Reply

Your email address will not be published. Required fields are marked *

*