Yea, that would be the concern... perhaps it should be a config setting
that one can set? [Where the DFS is fast, go there directly... where
not, stage through the local disk.]
Greg
On Fri, 23 Mar 2012, Richard Gass wrote:
If I remember correctly, there may have been an issue with writing to
the DFS when this code was written. During the suspend or migrate of
a non-persistent VM, the writing of the state needed to be very fast
in order to take a snapshot of the state, and continuously sync the
new changes until the current state was in sync with what was copied
to disk. In our case, the DFS was not a high performance filer but
just a machine with jbod attached disks. I think Mike would be able
to give more details about this one.
RIchard
On Fri, Mar 23, 2012 at 2:23 PM, Michael Stroucken <[email protected]> wrote:
I'm looking at improving the speed with which VMs can be suspended or
migrated, and I'd like to make a change to streamline things.
Currently, when a machine suspends, it writes its state to the local file
system. Once the dump is complete, the state file is copied into the DFS. On
resuming though, the state file is fed directly to qemu from the DFS.
I'd like to eliminate the copy and store the state file directly into DFS.
In my case, the DFS is a mount on a filer, provided courtesy of Netapp.
Writing directly to the Netapp cuts out a potential failure location plus it
provides higher performance versus the local drive.
I think it is a win, but I wanted to make sure that the suspend
functionality wasn't intentionally organized this way.
Thanks,
Michael.
--
Richard Gass
