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.
--
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
