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