incubator-tashi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kozuch, Michael A" <>
Subject RE: suspending machines in Tashi
Date Fri, 23 Mar 2012 19:48:10 GMT
I recall that there was an issue, but I don't recall what it was.

I do agree, though, that two copies seems unnecessary.  Another solution might be to store
the snapshot locally, and then send directly to the local disk on the target client.  It's
possible that this approach would be more scalable in that, if I were to migrate 100 VMs,
they wouldn't necessarily all use the same resource.


-----Original Message-----
From: Michael Stroucken [] 
Sent: Friday, March 23, 2012 2:23 PM
Subject: Re: suspending machines in Tashi

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.
If that was the reason, then it seems to be vestigial now, since the VM 
is stopped before beginning the state dump. At the time suspending 
starts, the VM's state should not change anymore.

Migration is separate from this, because that just sends the state over 
the network instead.

Our filer system isn't that high performance, but gigabit ethernet 
connectivity to a bunch of spindles beats out staging to partition 3 on 
a local disk that is shared with the OS and co-hosted VMs.

I've asked Mike for more information on what migration patches were put 
on at IRP, but I maybe Mike has that information at hand too. :)


View raw message