Michael Tokarev wrote: > Avi Kivity пишет: >> 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 update >>> it occasionally from the host? >> >> That's very fragile, since the guest won't expect the disk to change >> under its feet. Expect oopses. That is not what I meant, sorry if this was not clear enough. See below. > There's another way possible. Not sure if its feasible here due to > the amount of space it requires. Space is not really my concern here. Ease of management is. Especially if this allows many guests to share the same virtual disks, this would more than compensate for the extra copies. > 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... > [] >> 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. Which is why I had said "Note: I do not want to use the qemu monitor..." > 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! > There's no need to umount the filesystem in the guest if going "my way" > above. (as above: problem is that the guest will not be getting the new filesystem until it reboots...) >> 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. (not to mention the 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) Done. Thanks Antoine -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
