Virtualizing QNX 6.0

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm looking for any suggestions, and especially any real experiences,
that anyone cares to offer.

We have a system that includes an x86 box running QNX 6.something.  It
has the following interfaces:

-- network card for product specific data acquisition, 100 base T or
faster

-- network card to user workstation (Windows XP based), 100 base T or
faster

-- USB 2.0 high speed interface to machine control

-- Monitor output, 1024 X 768 32-bit color

-- Standard PC serial port to receive input from touch screen
integrated into above LCD monitor

-- Standard keyboard and mouse, used by service techs only during
service and updates, not the normal users

-- A CD or DVD drive for installing and upgrading the system

We are looking at the possibility of moving the QNX system and
application into a virtual machine on the workstation, which will be a
quad core, dedicating one core to QNX.  We are not looking to change
the QNX system significantly or more it to another RTOS.  There are
many years of development and use.  The QNX application has some real
time requirements, mostly related to the data acquisition, and
injecting timing date from the USB interface into the Ethernet
acquisition stream.

This is not really my part of the system, but the people working on
the Windows/QNX side asked me to see if I could find any options that
they might have missed.

They looked at Tenasys, but apparently that only runs QNX headless, so
it couldn't do the user GUI/touch screen functions.

They say VMware would work, but it is more expensive than they would
like.

So I would appreciate any experiences anyone has to share about
actually running QNX 6 under any x86 VM along with Windows and
achieving real time performance.

TIA,

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Virtualizing QNX 6.0
Quoted text here. Click to load it


...
check out QEMU, and also do a google search for "qnx qemu"

Re: Virtualizing QNX 6.0
AZ Nomad schreef:
Quoted text here. Click to load it

I'm not sure how well the QEMU solution would meet the 'real time
performance' the OP mentioned. Also QEMU is quite slow since it emulates
the processor as well.

Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I
think it is unlikely one will find a VM that allows guests OS'es to
provide hard real time guarantees while running in that VM.

Unfortunately the OP wasn't specific about the real time deadlines that
had to be met, or the host OS.

Re: Virtualizing QNX 6.0
Quoted text here. Click to load it
It

You may want to check out the Real-Time Systems Hypervisor. I know
that they give direct hardware access to a guest but I am not sure if
they allow you to run QNX with GUI or not.

Re: Virtualizing QNX 6.0
Quoted text here. Click to load it


Only I/O is emulated.  Programs run natively until they need to do I/O.  
Drivers are installed into the guest OS in order to provide native performance
for I/O as well.  It is the same with vmware.

Perhaps use a hypervisor solution such as XEN?  

Quoted text here. Click to load it

The non-RT OS is the one that should be running in a virtual environment.
Putting qnx in a virtual machine on a pig of an operating such as windows
would bring the windows lags to guest and host.

Quoted text here. Click to load it

Re: Virtualizing QNX 6.0
AZ Nomad schreef:
Quoted text here. Click to load it

Apparently you are talking about a different QEMU than I am, unless you
were talking about KQEMU.

Re: Virtualizing QNX 6.0
Quoted text here. Click to load it
wrote:
Quoted text here. Click to load it


I've used QEMU ahd it doesn't do processor virtualization.  For the most part
the guest OS runs at native speeds espcially after a driver is installed
into the guest OS.

Try valgrind if you want to see just what an emulated processor is like.
You're lucky if it runs at a twentieth native speed.

Re: Virtualizing QNX 6.0
AZ Nomad schreef:
Quoted text here. Click to load it
wrote:
Quoted text here. Click to load it
performance
Quoted text here. Click to load it

I've used QEMU (without the KQEMU driver) on a Windows PC, and it did
surely did emulate the processor (just like the author of this software
claims, check the website).

Quoted text here. Click to load it

Which is close to what I experienced with QEMU, much slower than native
or VMWare for example.


Re: Virtualizing QNX 6.0
Quoted text here. Click to load it
wrote:
Quoted text here. Click to load it
performance
Quoted text here. Click to load it


With the KQEMU driver, the only sane way of using QEMU when both the
host and guest OS are X86, QEMU virtualizes, not emulates.

From the QEMU website:
When used as a machine emulator, QEMU can run OSes and programs made for one
machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using
dynamic translation, it achieves very good performances.

When used as a virtualizer, QEMU achieves near native performances by executing
the guest code directly on the host CPU. A host driver called the QEMU
accelerator (also known as KQEMU) is needed in this case. The virtualizer mode
requires that both the host and guest machine use x86 compatible processors.

Re: Virtualizing QNX 6.0
AZ Nomad schreef:
Quoted text here. Click to load it
wrote:
Quoted text here. Click to load it
performance
Quoted text here. Click to load it

QEMU without the KQEMU driver is a very handy if you need a VM but don't
want to install something on the system and/or don't have administrative
privileges. E.g. one can run a (lightweight) Linux distro from a USB
stick in a window without rebooting and without changing a single thing
to the system.

Re: Virtualizing QNX 6.0

|--------------------------------------------------------------------------------|
wrote:|
|> > I'm looking for any suggestions, and especially any real experiences,      
|

|> > that anyone cares to offer.                                                
|

|>                                                                              
|

|> > We have a system that includes an x86 box running QNX 6.something.  It    
|

|[..]                                                                          
|
|                                                                              
|
|I'm not sure how well the QEMU solution would meet the 'real time performance'
|
|the OP mentioned. Also QEMU is quite slow since it emulates the processor as  
|
|well.                                                                          
|
|                                                                              
|
|Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think it is
|
|unlikely one will find a VM that allows guests OS'es to provide hard real time
|
|guarantees while running in that VM.                                          
|
|                                                                              
|
|Unfortunately the OP wasn't specific about the real time deadlines that had to
|
|be met, or the host OS."                                                      
|
|--------------------------------------------------------------------------------|

I have not used QNX in QEMU, but I have noticed that the throughput of
a simulated operating system in QEMU can be impressively high
(depending on what is being done) if the host operating system does
not need to use virtual memory for the simulation (i.e. if the
simulation can be kept within the host computer's main memory). The
high throughput is still accompanied by QEMU's high latency however. I
was not trying to access any external hardware, which may make this to
be a less useful example for Jack.

I do not know why the people Jack mentioned no longer want a perfectly
functioning QNX native installation. I used to study with someone
whose master's thesis was about a Windows system he developed by
porting a QNX application which he did not develop to Windows. Why do
people do these things?

Re: Virtualizing QNX 6.0
On Sun, 27 Jul 2008 12:12:45 +0100, Colin Paul Gloster

Quoted text here. Click to load it
|--------------------------------------------------------------------------------|
wrote:|
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
performance'  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
is |
Quoted text here. Click to load it
time  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
to  |
Quoted text here. Click to load it
  |
Quoted text here. Click to load it
|--------------------------------------------------------------------------------|
Quoted text here. Click to load it

Since you asked, I will be happy to reply.

Right now, the product (a medical imaging device) must ship with at
least two x86 computers.  One, the image acquisition computer, runs
QNX 6.something.  The other, which is the user workstation and
interface to the hospital/clinic network, DICOM translator, image
processor, archive, etc., runs under Windows XP.

Having two computers instead of one is an expense in and of itself.
Beyond this, it is a maintenance headache.  Any particular x86 box
these days is not available for a great length of time.  By the time
we are shipping a particular new computer, its end of life is already
announced and we are qualifying and validating the next one.

Seeing as how this is a medical device, which is a highly regulated
industry by the FDA in the US and corresponding agencies in other
countries and regions of the world, the overhead of testing and
documenting any change in hardware is quite substantial.

Right now we are continuously validating not one, but two different
replacement computers at any give time, for two different sets of
operating systems and applications.

If we can successfully run QNX and the application on a VM under XP,
there is now only one computer to validate for hardware updates.

The other great savings potential is simply the fact that new x86
hardware (motherboards, BIOS, network cards, etc.) always ship with
Windows driver support.  It is not always so easy or quick to have or
get QNX drivers for the latest, newest hardware.

At least some VM implementations virtualize hardware interfaces such
as NIC, serials ports, USB controllers, so they look generic to the
guest OS.  That can also save some headaches.

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Virtualizing QNX 6.0


Quoted text here. Click to load it

If at all possible, you should have XP in the VM.  A RTOS in a VM on a
pig like XP will have the same lockups that every XP process is
prone.

Baring that, why not just have two PC's sitting side by side?  How
tightly coupled are the operating systems in the final application?
How do they interface?

Re: Virtualizing QNX 6.0
On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad

Quoted text here. Click to load it

There are (or at least have been) rack mountable boxes available with
two separate passive backplanes with separate power supplies. Add just
a KVM switch and the system looks just like a "single computer" as the
customer wanted. Of course you can run different operating systems or
even different processors on the two backplanes.

Paul


Re: Virtualizing QNX 6.0
Quoted text here. Click to load it



I bet they cost a heck of a lot more than two PC's.


Re: Virtualizing QNX 6.0
Quoted text here. Click to load it

Yes, but they'll be stable and avaialable for 10 years.

The industrial computer market is much better behaved, in terms
of deployments, than the consumer market.

I'll third (fourth, fifth) the votes to have XP be the virtualized
OS underneath something else.  There are very probably good reasons
the original designers are using QNX, most likely having to do with
the  fact that it's a real-time system.  XP simply can not provide
real-time guarantees.

Oh, and it's increasingly hard to get XP, too.

Depending on exactly how Windows-dependent the user interface
code is, it could probably be ported to run on QNX.
--
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
We've slightly trimmed the long signature. Click to see the full one.
Re: Virtualizing QNX 6.0
On Sun, 27 Jul 2008 23:12:35 -0500, AZ Nomad

Quoted text here. Click to load it

Sure it is, but my guess is that the computer box cost is
insignificant compared to the total life cycle costs of the OP's
system.

My experience with passive backplanes is from the days of ordinary PCI
backplanes, the PCI Express may have complicated things.

Paul


Re: Virtualizing QNX 6.0



Paul Keinanen wrote:
Quoted text here. Click to load it

And, if he buys server-class rather than consumer-class PCs,
his "By the time we are shipping a particular new computer,
its end of life is already announced and we are qualifying
and validating the next one" problem will go away.



--
Guy Macon
<http://www.GuyMacon.com/


Re: Virtualizing QNX 6.0


Quoted text here. Click to load it

Is this ordinary Win XP or Win XP Embedded ? If XP, I would be quite
concerned with the remaining life cycle for XP, the Win XXX Embedded
versions have had at least in the past a longer life cycle (e.g. no
W2k Embedded, so NT4 Embedded lived for quite a long time).

Quoted text here. Click to load it

I do not know about the processing power requirement for your QNX
system, but usually the x86 embedded boards have a much longer life
cycle then ordinary desk top boxes. However, the RoHS requirements may
prematurely terminate the production of some older non-RoHS boards due
to lack of non-RoHS components.

For the user interface box, you are still going to have to replace the
box due to the increasing resource requirements of future Windows
operating systems.

Quoted text here. Click to load it

At least for the QNX box, you should be able to extend the life cycle
and thus reduce the requalification costs, with suitable choice of
hardware, especially if you do not need the absolute top performance
for the application.

Quoted text here. Click to load it

When there are some severe realtime requirements for a system running
a general purpose OS (Such as Windows or Linux), the usual practice is
to use a real time extension, which in practice is a RT-kernel running
the RT application and then running the general purpose
(Windows/Linux) OS as the null/idle task in the RT-kernel, using the
unused CPU would have otherwise been used by the idle loop.  

Quoted text here. Click to load it

Do you absolutely need the newest hardware for performance issues or
due to end of production for the older card ?

Paul


Re: Virtualizing QNX 6.0

Quoted text here. Click to load it

That requirement sounds that you should use more than two computers
(or at least several XP systems in VMware etc.). Keep the QNX system
on a separate hardware and the VM system on a different hardware.

It would be natural to keep the general XP specific part on one VM and
the country and hospital specific part on the other XP VM. It is quite
likely that the hospital side may be updated at some time different
for the update time of the rest of the imaging system.

By the way, for how long are you required to provide spare parts and
support for your system, one year, three years or ten years or more ?
This will also dictate what kind of hardware to use and how to
partition the functionality into different (real or virtual) boxes.

Paul
 

Site Timeline