Re: sharing a (mostly) read-only virtual block device

[Avi Kivity <avi@redhat.com>]

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.