From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTZc8-0003GU-7f for qemu-devel@nongnu.org; Thu, 14 Aug 2008 05:59:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTZc5-0003Fj-LG for qemu-devel@nongnu.org; Thu, 14 Aug 2008 05:59:26 -0400 Received: from [199.232.76.173] (port=40948 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTZc4-0003FQ-Em for qemu-devel@nongnu.org; Thu, 14 Aug 2008 05:59:24 -0400 Received: from mail2.shareable.org ([80.68.89.115]:44317) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KTZc4-00019G-51 for qemu-devel@nongnu.org; Thu, 14 Aug 2008 05:59:24 -0400 Date: Thu, 14 Aug 2008 10:59:20 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] VistA on QEMU Message-ID: <20080814095920.GB682@shareable.org> References: <200808140155.53107.nanthracite@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808140155.53107.nanthracite@verizon.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: nanthracite@verizon.net, qemu-devel@nongnu.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