From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: sharing a (mostly) read-only virtual block device Date: Sun, 18 Oct 2009 12:32:19 +0400 Message-ID: <4ADAD293.3010004@msgid.tls.msk.ru> References: <4AD84EB5.5070200@nagafix.co.uk> <4ADABD7C.50803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Antoine Martin , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:37100 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751362AbZJRIcR (ORCPT ); Sun, 18 Oct 2009 04:32:17 -0400 In-Reply-To: <4ADABD7C.50803@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 10/16/2009 07:45 PM, Antoine Martin wrote: >> Hi, >> >> Is there an easy way that I have missed to share a virtual disk >> read-only between many guests whilst still having the ability to upd= ate >> it occasionally from the host? >=20 > That's very fragile, since the guest won't expect the disk to change=20 > under its feet. Expect oopses. There's another way possible. Not sure if its feasible here due to the amount of space it requires. The idea is to move the original _unmodified_ image out of the way but = keep it. All guests who have it open now will keep it open and will not see= the changes. But you now require at least 2x space - for old image and for= the new one. Or more, if you want to keep some guests running for longer so= they still refer to pre-last or pre-pre-last image version. It can be done by preparing the new file as foo.new and moving it into = place by mv. The old file gets removed from the directory but not removed ph= ysically from the filesystem, till all the references to it (open by another pro= cess) will be gone. [] > I suggest using a monitor, and have the host and guest coordinate the= =20 > change (guest unmounts, host modifies, guest mounts). Yes that's the way to go. Or, simpler, reboot the guest(s). There's no need to umount the filesystem in the guest if going "my way"= above. > Alternatively, export the disk from the host using nfs. And yes, that's also a very good idea. /mjt