[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] VistA on QEMU
Re: [Qemu-devel] VistA on QEMU
Thu, 14 Aug 2008 08:11:14 -0400
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:
> > 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