On Apr 20, 2010, at 4:44 PM, Geoff Nordli <geo...@grokworx.com> wrote:
From: matthew patton [mailto:patto...@yahoo.com]
Sent: Tuesday, April 20, 2010 12:54 PM
Geoff Nordli <geo...@grokworx.com> wrote:
With our particular use case we are going to do a "save
state" on their
virtual machines, which is going to write 100-400 MB
per VM via CIFS or
NFS, then we take a snapshot of the volume, which
guarantees we get a
consistent copy of their VM.
maybe you left out a detail or two but I can't see how your ZFS
snapshot
is going to be consistent UNLESS every VM on that ZFS volume is
prevented from doing any and all I/O from the time it finishes "save
state" and you take your ZFS snapshot.
If by "save state" you mean something akin to VMWare's disk snapshot,
why would you even bother with a ZFS snapshot in addition?
We are using VirtualBox as our hypervisor. When it does a save
state it
generates a memory file. The memory file plus the volume snapshot
creates a
consistent state.
In our platform each student's VM points to a unique backend volume
via
iscsi using VBox's built-in iscsi initiator. So there is a one-to-one
relationship between VM and Volume. Just for clarity, a single VM
could
have multiple disks attached to it. In that scenario, then a VM
would have
multiple volumes.
end we could have
maybe 20-30 VMs getting saved at the same time, which could
mean several GB
of data would need to get written in a short time frame and
would need to
get committed to disk.
So it seems the best case would be to get those "save
state" writes as sync
and get them into a ZIL.
That I/O pattern is vastly >32kb and so will hit the 'rust' ZIL
(which
ALWAYS exists) and if you were thinking an SSD would help you, I
don't
see any/much evidence it will buy you anything.
If I set the logbias (b122) to latency, then it will direct all sync
IO to
the log device, even if it exceeds the zfs_immediate_write_sz
threshold.
If you combine the hypervisor and storage server and have students
connect to the VMs via RDP or VNC or XDM then you will have the
performance of local storage and even script VirtualBox to take a
snapshot right after a save state.
A lot less difficult to configure on the client side, and allows you
to deploy thin clients instead of full desktops where you can get away
with it.
It also allows you to abstract the hypervisor from the client.
Need a bigger storage server with lots of memory, CPU and storage
though.
Later, if need be, you can break out the disks to a storage appliance
with an 8GB FC or 10Gbe iSCSI interconnect.
-Ross
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
