From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: sharing a (mostly) read-only virtual block device Date: Mon, 19 Oct 2009 10:51:08 +0900 Message-ID: <4ADBC60C.3020906@redhat.com> References: <4AD84EB5.5070200@nagafix.co.uk> <4ADABD7C.50803@redhat.com> <4ADAD293.3010004@msgid.tls.msk.ru> <4ADB092F.2010906@nagafix.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , "kvm@vger.kernel.org" To: Antoine Martin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6799 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753291AbZJSBv5 (ORCPT ); Sun, 18 Oct 2009 21:51:57 -0400 In-Reply-To: <4ADB092F.2010906@nagafix.co.uk> Sender: kvm-owner@vger.kernel.org List-ID: On 10/18/2009 09:25 PM, Antoine Martin wrote: >> 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 >> physically >> from the filesystem, till all the references to it (open by another >> process) >> will be gone. >> > This is exactly the solution I suggested in my original post. (which got > snipped out) > > The problem with this one is that (quote from original post): > "Unfortunately qemu opens the virtual disk as soon as the guest boots, > so the file descriptor still points to the old image." > > Which means that the guest will not see the new file until it is rebooted. > > So close... yet so far... > You can try to use the cdrom support. Eject the old disk, insert the new disk. >>> I suggest using a monitor, and have the host and guest coordinate the >>> change (guest unmounts, host modifies, guest mounts). >>> > In terms of ease of management, that's far from ideal. > This requires the guests and hosts to co-operate. These may not be > managed by the same people. > Write a bit of software to coordinate. > Which is why I had said "Note: I do not want to use the qemu monitor..." > The guest and host have to cooperate. The host has no notion of the guest mounting and unmounting the filesystem. >> Yes that's the way to go. Or, simpler, reboot the guest(s). >> > Again, not ideal. Having to reboot just to get access to a file that is > just there waiting... is frustrating! > Rebooting won't actually help, since it won't reopen the file. >>> Alternatively, export the disk from the host using nfs. >>> >> And yes, that's also a very good idea. >> > One I had considered and that I dislike for the same reasons I mentioned > above. The sheer number of processes and ports involved on the host > makes me cringe. When trying to get close to bare-metal on the host, > running network daemons like nfs is just not going to happen. > Is this measured overhead or assumed overhead? > (not to mention the security considerations) > What security considerations? > I would much prefer a solution involving just shared read-only files. > > I realize that it is probably quite hard (if not impossible) to tell > qemu to re-open the disk image the next time that the guest unmounts the > existing disk image. That's a shame, because it would do the job nicely: > 1) signal qemu > 2) guest unmounts/remounts (whenever it wants) > Try ejecting the cdrom, it may work for you. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.