On Wed, Feb 03, 2016 at 02:31:06PM +1100, Colin Fee wrote:
Hi Craig,
sorry to take sso long to reply, just got back home from hospital (after 14 days! getting my T-cells wiped out so they stop treating my shiny new kidney as a foreign invader to be attacked). if you've got any specific questions or just want to pick my brains for some general tips, feel free to ask.
I'm interested in your solution above. My team and I support research at Monash Uni and increasingly are supporting legacy hardware and windows OSs used to drive specialist instruments. Often, as you'd be familar, the PC is supplied by the instrument vendor with the instructions like we won;t support this if you deviate from our installation etc or we won't support if you use a different PC.
well, support from the supplier is a different story. fortunately in this particular case we (IT @ chemistry, unimelb) got involved early in the purchase (which was quite unusual, it was far more common for the researchers to say "here's our shiny new machine, get it on the network for us") and were able to have some input and control into how the instrument could be connected to the network. the supplier wanted to make the sale, so worked with us (or at least, didn't obstruct us which was good enough) the easiest instruments to deal with use a standard interface, ethernet-connected devices are great - just give it a private network. otherwise GPIB or something "reasonably" standard is good. education of the researchers is vital - they need to know to ask about interfaces and connectivity, otherwise they'll spend a fortune on something with a proprietary interface which will be obsolete and deprecated by the supplier long before the useful life of the instrument is over....and when you're spending $100K on an instrument you want to get more than 3-5 years out of it.
A competing tension them comes from the researchers, we want to acces the corporate network etc.
that's why we used a linux box as a buffer - a relatively safe way of providing network access to the instrument. As well as access via the console, VNC and RDP clients also provided remote access to the virtualbox windows desktop, which had direct access to the instrument and access to the samba file shares.
Then comes a time when the PC has aged/failed, we can't ge the acient OS (XP, NT) to run on modern hardware...and so on.
one of the problem instruments I had to keep going was an ancient IFIR in one of the student teaching labs, connected via an ISA-bus instrument to a machine running win95 - for obvious reasons this was NOT connected to the rest of the network, so sneakernet was used to transfer files. the IFIR still worked perfectly (for something that was bought in the early 90s) and replacing it with something new would have cost $60K+, so keeping it going as long as possible was highly desirable. I have no idea if it's still there or not (it was when moved on to Nectar a few years ago), but it is doomed to eventually be scrapped, though, because our attempts to replace the win95 box with an industrial PC (about the only things still having ISA buses these days) kept running into all sorts of failures and problems (mostly that even the ind. PCs had CPUs and RAM and other built-in components that were too new for win95 or even win98).
So I assume by vbox you mean VirtualBox? I'm not overly familiar with it (I've run it for curisoty sake but haven't looked into at depth) but your post suggests that it's more apt to be given or configured for deeper access to hardware than say VMware?
yep, virtualbox. chosen mostly because it was free (i.e. all the required features were available in the free version), whereas vmware isn't. kvm at the time didn't allow direct pass-through to GPUs, USB ports, etc. for this sort of job, i'd probably still choose virtualbox - it just seems better suited to the task, as the instrument-controller PC is a specialised single-purpose machine. for server-type VMs, though, i'm inclined to use KVM, which is great for running dozens or hundreds of VMs on one server. i've got nothing against vmware in particular, just don't see any compelling reason to use it instead of either kvm or virtualbox. the management tools aren't anything special, perhaps prettier and simpler for novices than virsh etc, but that's not so important for someone experienced. craig -- craig sanders <cas@taz.net.au>