incubator-tashi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ganger <>
Subject Re: suspending machines in Tashi
Date Fri, 23 Mar 2012 15:28:16 GMT

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


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

View raw message