[Qemu-devel] VistA on QEMU

[Qemu-devel] VistA on QEMU

[Nancy Anthracite]

I signed up for this developers list specifically to find the experts I needed 
to ask this question.  

I am the volunteer CMO of WorldVistA (www.worldvista.org).  We are a 
charitable non-profit that promotes the use of the Department of Veterans 
Affairs' VistA outside of the VA. VistA is an M based,  open source, medical 
records and hospital management system.  We have a version of it that is 
called WorldVistA EHR and all code we have added to it all carries the GPL 
version 2 or later license.  WorldVistA EHR is the only CCHIT certified open 
source medical records system to my knowledge.

Now all of this leads up to my question.  We very much like putting demos of 
VistA on QEMU machines on Linux with GT.M. That gives us a totally open 
source stack.  But I have been reluctant to recommend QEMU for a production 
system because I don't think there would be "hard writes" of the data entered 
into the M database to a hard disk on a QEMU machine, and thus if there were 
loss of power, and unpredictable amount of patient related data could be 
lost.

I wonder if I am correct in that assumption or not, and if I am, if there 
might be an option that could be invoked, as I understand can be invoked on a 
VMWare virtual machine, to actually write data to the hard disk right away.

Ultimately we would like to distribute configured, ready to use virtual 
machines for doctors to use in their offices with backup other virtual 
machines that can be placed remotely for accepting data for backup.  It would 
make the  use of VistA much easier and far more user friendly.

Any help you can give me would be much appreciated.  I promise not to hang 
around bothering you on a developers list where I don't really belong for 
long.
-- 
Nancy Anthracite, MD
Chief Medical Officer
WorldVistA
nancy@worldvista.org
301-738-2150

Re: [Qemu-devel] VistA on QEMU

[Jamie Lokier]

Nancy Anthracite wrote:
> Now all of this leads up to my question.  We very much like putting
> demos of VistA on QEMU machines on Linux with GT.M. That gives us a
> totally open source stack.  But I have been reluctant to recommend
> QEMU for a production system because I don't think there would be
> "hard writes" of the data entered into the M database to a hard disk
> on a QEMU machine, and thus if there were loss of power, and
> unpredictable amount of patient related data could be lost.

QEMU is able to commit "hard writes" already.

There's a couple of choices: (1) With default options, it calls the
host's fsync() or equivalent system call triggered by a chain of
events from the guest database asking to commit data.  Or (2) You can
mount the disk image with cache=off to the QEMU command line, which
uses "direct writes" - not quite the same thing.

Unfortunately, the host operating system - whether Linux or Windows -
may or may not convert fsync() calls or direct writes to "hard
writes".  It depends on the host OS version and its configuration, and
on the hardware.

If the host doesn't "hard writes", it usually does what you might call
"semi-hard" (except there are rumours some older versions of Windows
don't bother with that either).  Power loss events can result in some
data loss, but it's relatively limited in the amount of data, and over
a relatively short time interval.  Business critical databases like
banks would care, but I don't know how important this relatively
unlikely event is to you.

There are quite a few conditions to be satisfied if you need to be
_certain_ a guest database's write is translated all the way through
to a "hard write" on the host disk.  Most of them are outside QEMU's
control (and outside VMware's too.)

You should know that if the guest is Linux, you should make sure the
*guest* filesystem is setup to send "barrier" requests.  This is _not_
enabled by default for ext3 on most Linux guests.

> I wonder if I am correct in that assumption or not, and if I am, if
> there might be an option that could be invoked, as I understand can
> be invoked on a VMWare virtual machine, to actually write data to
> the hard disk right away.

VMware has a similar limitation: if the host operating system doesn't
commit data, or the disk controller (especially RAID controllers)
don't, or the disk itself doesn't (some ATA disks, not many current
ones I'd guess), or if the guest operating system doesn't send barrier
requests, then VMware can't force it to happen.

These two pages from Microsoft describe the conditions under which
"hard writes" happen for real on a Windows host.  They are about SQL
Server, but the same applies to any program which needs to store data
locally with high reliability:

http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
http://www.microsoft.com/sql/alwayson/storage-requirements.mspx

> Ultimately we would like to distribute configured, ready to use
> virtual machines for doctors to use in their offices with backup
> other virtual machines that can be placed remotely for accepting
> data for backup.  It would make the use of VistA much easier and far
> more user friendly.

Sounds good.  If you're doing remote backup anyway, is the networking
in doctors offices good enough to store the database commits remotely
when they happen, so you don't have to rely on their local Windows
installation being reliable?

-- Jamie

Re: [Qemu-devel] VistA on QEMU

[Nancy Anthracite]

Thank you very much for your very helpful response.  I will forward this on to 
our Linux gurus later today and check into the barrier issue as I have never 
heard of that.   Also, I was not aware of the RAID problem either.

It is interesting that you mentioned banks, because that is where GT.M in its 
non-GNU versions is used - in banks - many of them very large, but I am sure 
not on virtual machines. 

Thanks so much for the wonderful work you and others are doing with QEMU.  We 
are real fans of QEMU.  ;-)

On Thursday 14 August 2008, Jamie Lokier wrote:
> Nancy Anthracite wrote:
> > Now all of this leads up to my question.  We very much like putting
> > demos of VistA on QEMU machines on Linux with GT.M. That gives us a
> > totally open source stack.  But I have been reluctant to recommend
> > QEMU for a production system because I don't think there would be
> > "hard writes" of the data entered into the M database to a hard disk
> > on a QEMU machine, and thus if there were loss of power, and
> > unpredictable amount of patient related data could be lost.
>
> QEMU is able to commit "hard writes" already.
>
> There's a couple of choices: (1) With default options, it calls the
> host's fsync() or equivalent system call triggered by a chain of
> events from the guest database asking to commit data.  Or (2) You can
> mount the disk image with cache=off to the QEMU command line, which
> uses "direct writes" - not quite the same thing.
>
> Unfortunately, the host operating system - whether Linux or Windows -
> may or may not convert fsync() calls or direct writes to "hard
> writes".  It depends on the host OS version and its configuration, and
> on the hardware.
>
> If the host doesn't "hard writes", it usually does what you might call
> "semi-hard" (except there are rumours some older versions of Windows
> don't bother with that either).  Power loss events can result in some
> data loss, but it's relatively limited in the amount of data, and over
> a relatively short time interval.  Business critical databases like
> banks would care, but I don't know how important this relatively
> unlikely event is to you.
>
> There are quite a few conditions to be satisfied if you need to be
> _certain_ a guest database's write is translated all the way through
> to a "hard write" on the host disk.  Most of them are outside QEMU's
> control (and outside VMware's too.)
>
> You should know that if the guest is Linux, you should make sure the
> *guest* filesystem is setup to send "barrier" requests.  This is _not_
> enabled by default for ext3 on most Linux guests.
>
> > I wonder if I am correct in that assumption or not, and if I am, if
> > there might be an option that could be invoked, as I understand can
> > be invoked on a VMWare virtual machine, to actually write data to
> > the hard disk right away.
>
> VMware has a similar limitation: if the host operating system doesn't
> commit data, or the disk controller (especially RAID controllers)
> don't, or the disk itself doesn't (some ATA disks, not many current
> ones I'd guess), or if the guest operating system doesn't send barrier
> requests, then VMware can't force it to happen.
>
> These two pages from Microsoft describe the conditions under which
> "hard writes" happen for real on a Windows host.  They are about SQL
> Server, but the same applies to any program which needs to store data
> locally with high reliability:
>
> http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.
>mspx http://www.microsoft.com/sql/alwayson/storage-requirements.mspx
>
> > Ultimately we would like to distribute configured, ready to use
> > virtual machines for doctors to use in their offices with backup
> > other virtual machines that can be placed remotely for accepting
> > data for backup.  It would make the use of VistA much easier and far
> > more user friendly.
>
> Sounds good.  If you're doing remote backup anyway, is the networking
> in doctors offices good enough to store the database commits remotely
> when they happen, so you don't have to rely on their local Windows
> installation being reliable?
>
> -- Jamie



-- 
Nancy Anthracite