Licensing LabVIEW with Docker Images

Recently there has been a lot of questioning concerning the licensing of the LabVIEW inside container images, mainly after one of my posts about using LabVIEW with Docker.

In this post, I am going to discuss one of the methods that I used successfully for a long time, and without any problems, I mean, only a small one that I will discuss later.

Licensing with VLM

Although there are another methods, as mentioned by Chris Stryker and Dhagal, those methods relies on the license files generated by the License Manager and usually they are tied to specific machine configuration (hard disk, network adapter, computer hostname, etc…) and you might need to contact NI for support (if you have SSP or some technical support contract).

So, for me it was not feasible, as I wanted something more dynamic and not to worry about where I would be running the CI Runner.

For this reason, I chose the Volume License Manager option, which is a Software from NI that manages multiple licenses, usually the customer is eligible when has 5 or more licenses. But it depends on each case.

That I would say it is the biggest drawback of this method. There are others of course, but I will comment about it in the two different methods that it is possible to use.

Using VLM with Computer Based License

This is the by far the easiest way of working with it. That is usually a reality in companies that have an Enterprise Agreement with NI, or you have bought licenses that allows you to connect dynamically independently of the user/computer, as long as you have seats available.

In this case, you can use the method mentioned in my post.

All you need is to sign up the Container Hostname in Computers Tab (I don’t recall the docker hostname for images, but it tends to be the same for gitlab-runner). And on every run of your image, you add the remote Volume License Manager with the License Manager Command Line:

NILicensingCmd.exe /silent /addservers $VLM

where $VLM stands for the IP address or the Hostname of the machine hosting the VLM.

While running the container, docker will use one seat, so if you are limited on licenses, you may have failing jobs because the runner (e.g. gitlab-runner) couldn’t assign a license to the LabVIEW inside the container.

Using VLM with Name Based Licenses (Single Seat)

This is another method of licensing LabVIEW with VLM. In this case, the license is tied to the User, so you can’t use dynamically with different computers and different users. During the time I was working in my old job there was a licensing migration from the type mentioned above to this one, so I needed to adequate the process.

The alternative now was adding the Docker Default User to the Users Table and assign a license. (Be aware that this license is taken by Docker, and you won’t be able to use in other machines, even if Docker is not running).

So, what is the Docker Container default user?

The problem is right there. The default user is named ContainerAdministrator. If you count the chars, you will notice that is more than 20 chars long. And for Windows that is a problem, try to add this user to the VLM or to a Windows Machine, you probably be limited to ContainerAdministrat.

How to solve this?

I solved this by modifying Docker Default user. In my base image, I added those lines to the Dockerffile that:

1. adds the user,

2. assign administrative privileges (you want to install things later).

RUN net user Container /add

RUN net localgroup administrators Container /add

USER Container

After that, you can add the user mentioned in the Dockerfile, in this case Container, to the VLM and before every run, you may also want to call the License Manager.

The other option is of course adding the licensing to the Dockerfile, but that means if something changes in the VLM configuration you will have to rebuild all your images, or run this command again before you call LabVIEW.

Is there workarounds for adding user with more than 20 chars? Probably, but it is not worthy, and you spend more time doing this than adding the lines to the Dockerfile. If you are asking, yes, I tried.

Future

I hope that in not so far future we could also license container with LV community edition, but that would require modifications in the license scheme and also in the License Manager application, and this is probably not a priority, but let’s be optimistics.

See you in my next post.