Re: [Qemu-devel] VistA on QEMU

[Jamie Lokier <jamie@shareable.org>]

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