LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Managing Multiple LabVIEW Versions (copied from neohio group - jaredforshey)

When creating a VM from scratch, you do need the guest OS disk (and license). With VMware, there are tools (see VMware player page) that let you convert an existing system to a virtual machine.

I haven't had any issues with performance with VMware due to three things:

1. VT-x / VT-d extensions on the CPU - the mid to upper end Intel and AMD processors have virtualization extensions built into the CPU. This effectively lets the VM run on the CPU rather than going through a software layer, so it's at least 3x faster.

2. I have tons of RAM on my desktops and laptops (8GB minimum) as I often run multiple virtual machines at the same time. I give most VMs 2GB or 3GB, as well as let them have 2 CPU cores. You'd probably be fine with 1GB and 1 core, but more is better.

3. I use SSDs for all my computers, with the VMs on the SSDs when possible. With just one VM running, the SSD will help quite a bit, but if you have multiple VMs running at the same time, a spinning HD will kill your performance.

Of these things, #1 is by far the most important. If you don't have VT-x, you're dead in the water with VMs. Here's a link to see all the Intel processors with VT-x: http://ark.intel.com/search/advanced/?s=t&VTX=true You'll want narrow it down by family, but most of the i5 and i7 processors have it.

So, I see no noticable performance difference with my VMs vs. the host OS, even when compiling FPGA code on the guest and host at the same time. I think VirtualBox and VMware would perform about the same on the same hardware.

Message 11 of 22
(1,756 Views)

We almost always use virtual PCs: not just to separate LabVIEW versions, but we have a separate VPC for each project. Hardware access usually isn't an issue, as a lot of our hardware work is done on a deploy machine. If you want to have only one Vpc per version of LabVIEW, then I strongly suggest you ook at getting VIPM Professional, so you can easily roll your development environment back and forward between project configurations with VI package configurations.





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 12 of 22
(1,756 Views)

Excellent point Chris, I haven't gone to that level to have one for each project (yet), but I think it's a pretty wise idea.  I'm probably going to have to bite the bullet and get the grown-up version of VIPM; too many useful features.

0 Kudos
Message 13 of 22
(1,756 Views)

FYI on VirtualBox vs. VMware... Both support multiple monitors, 64bit guest OS's and configurable number of virtual cores, so you're good there. These are indespensible features IMHO.

0 Kudos
Message 14 of 22
(1,756 Views)

Hi!

I suggest you to use a real OS (Linux) on your host! Many of your issues will be solved.

I always use 64-bit Linux server OS as a host with VirtualBox to have many VMs, separate for each LV versions and also for projects.

You can easily create VM templates from fresh installs: default WinXP, Win7, LVx.y within Win z, etc.

If you need a new VM, you simply can create a new instance from a template, which takes only a few seconds (copying the VM disk image to a new location).

I never ever had problems with USB devices. Right now I'm working on accessing PCI devices installed in the host from VMs, but this needs VT-d (VT-x is not enough!).

You can easily create scripts for all your VBox tasks (using VBoxManage CLI).

If you need some pretty GUI to manage your VMs, you can use phpvirtualbox which adds a nice web interface.

VBox vs. VMWare: VBox has a really huge non-enterprise user base, so I'm sure you will always find some help or solution on forums for your problems. Don't forget that VBox is open-source, so as a last resort you always can dig in to the source code!

Regards,

Peter

0 Kudos
Message 15 of 22
(1,756 Views)

I'd like being able to use a virtualization approach, but in this forum thread Seth B.told me virtualization is not officially supported by NI.

As I said in that discussion, I confirm that with Virtualbox you have to install the same DAQmx dirvers version both on the host machine and on the guest one: otherwise some of the USB acquisition devices won't work in the virtualized system.

Can someone confirm that with WMWare different DAQmx version can be successfully used?

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 16 of 22
(1,756 Views)

Our IT is moving us to VMware from Virtual PC. We're developing for E- and M-series DAQ, CAN and FPGA cards besides whatever serial, USB and ethernet devices come our way. We've heard good things about the abilities of VMware to perform hardware virtualization (mainly from IT people); we're not expecting great things, but Virtual PC has none so this will be an improvement.

0 Kudos
Message 17 of 22
(1,756 Views)

peter_smith wrote:

I suggest you to use a real OS (Linux) on your host! Many of your issues will be solved.

Could you qualify that? What issues are solved by using Linux as a host, as opposed to, say, Windows 7 64bit?

peter_smith wrote:

You can easily create VM templates from fresh installs: default WinXP, Win7, LVx.y within Win z, etc.

If you need a new VM, you simply can create a new instance from a template, which takes only a few seconds (copying the VM disk image to a new location).

Absolutely - we use that too.  The challenge is often to know what to put in the template, and what to leave out (eg: our templates are very sparse, with no NI software at all, as our needs often change radically between projects).  I think that starting from a template is certainly faster, but unless you're tied to particular LabVIEW/TestStand/Toolkit/driver/OS update versions, then it can take several hours to download and install any OS updates and install the components you really need for a project.





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 18 of 22
(1,756 Views)

Hi Christopher,

I use Linux as a host because of the following reasons:

  • It has a much smaller footprint than Windows in all aspects (memory usage, disk usage, etc) - As we use Type 2 hypervisors, we should make sure the host uses as little resources as possible...
  • It is much stable than Windows
  • Windows has so much overhead (like NTFS, registry) that all eat up your resources
  • I use LVM, so I can freely resize my volumes as needed
  • PCI passthrough is only supported under Linux

As per the templates:

I have templates of clean installs of the OSes and templates for each LV version.

I also have a local copy for NI installers (both SW packages and Device drivers). You can save a lot of time with that.

I use SVN to store my projects. If I have to move a project to a new LV version, I just spin up a new VM, create a branch from the project and check it out to the new VM.

About updates:

LV Updates are handled in the way I described above. Windows Updates: The first thing I always do after windows install is finished to disable automatic updates. I think windows updates will never affect your LV projects (I mean I never had a project where I needed a specific Win. update to make my LV code run), but they can affect stability of Windows itself (many times they make it even worse).

Of course, I don't think we should go into an argument about Linux vs. Windows. There are many discussions about that elsewhere. I just wanted to tell why and how I use this setup.

Regards,

Peter

0 Kudos
Message 19 of 22
(1,756 Views)

peter_smith wrote:

I use Linux as a host because of the following reasons:

  • It has a much smaller footprint than Windows in all aspects (memory usage, disk usage, etc) - As we use Type 2 hypervisors, we should make sure the host uses as little resources as possible...
  • It is much stable than Windows
  • Windows has so much overhead (like NTFS, registry) that all eat up your resources
  • I use LVM, so I can freely resize my volumes as needed
  • PCI passthrough is only supported under Linux
...

Of course, I don't think we should go into an argument about Linux vs. Windows. There are many discussions about that elsewhere. I just wanted to tell why and how I use this setup.

Oh, I agree completely - I wanted to know in case the benefits suggested that I might start using Linux as a host OS, not to start a Linux vs Windows agrument.  That said, I think I'll stick with Windows 7 as my host OS for now, as I use the same host as my standard working PC, and the only thing on your list that would have any impact on my development would be PCI passthrough, and even that's not a big deal for me.  I don't have any evangelical ties to a particular OS, I'm just interested in using something that helps me get my work done in the most efficient way with the highest value, and that's Windows 7 for the most part.

peter_smith wrote:

I have templates of clean installs of the OSes and templates for each LV version.

EIther you don't use a lot of LV versions and OSes, or you've got a *lot* of VM templates

peter_smith wrote:

LV Updates are handled in the way I described above. Windows Updates: The first thing I always do after windows install is finished to disable automatic updates. I think windows updates will never affect your LV projects (I mean I never had a project where I needed a specific Win. update to make my LV code run), but they can affect stability of Windows itself (many times they make it even worse).

I'd agree iff you don't ever expect to access the internet with the VMs, otherwise you need a lot of those updates to keep your VM secure, and not used as a bot. Also, there are often updates to drivers and subsystems that work I do with LabVEIW relies on (eg: .net).  Either way, whether you choose to apply Windows updates is up to you, although I'd suggest having your VM at the same level as the machine you're eventually going to deploy to, otherwise you could be in all sorts of surprises ("but it worked fine on my stripped-down, no updates installed, no virus scanner, old drivers VM, I don't know why it doesn't work on the latest-virus definition, up to date delployment PC!").





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 20 of 22
(1,756 Views)