JF> Yep, understood. I think my biggest problem with the
JF> SnapshotService is that I have a hard time thinking about snapshots
JF> that don't include a disk component - even more so in the context of
JF> multiple snapshots. This to me is the usefulness of
JF> SnapshotService. I can happily take snapshots (either just disk or
JF> disk + memory) and then sometime later select one to apply and end
JF> up with a functional system.
Right, and that's where the snapshot service will start to become much
more useful, when we can support that sort of behavior on one or more
platforms.
JF> From a client's perspective I just think it is cumbersome to use the
JF> SnapShotService to implement the notion of suspend. IMO, either the
JF> providers should support suspend or not. Currently they don't (as
JF> indicated in capabilities) but after invoking CreateSnapshot the vm
JF> is in suspended state - so they kind of do. Folks here writing
JF> client code are a little confused by this :-).
But in the future, when we do have coordinated snapshots, would you ever
really want to do a suspend instead of a snapshot? The danger of
someone corrupting their disk is definitely higher, and I don't think
there are any performance benefits for most storage types. So my point
is: when we get to that point, even if we support suspend as a state
transition, it would still be a "you should really be using the snapshot
service instead" kinda thing, I think.
JF> So I think it is safe to say that from client's perspective the
JF> providers don't support the suspended state. That said, they can
JF> achieve the same effect by means of {Create,Apply}Snapshot with the
JF> vendor defined values.
Okay, I'm happy with that for now. If it becomes an issue, perhaps we
can target a behavioral change to coincide with a significant version
bump.
Thanks Jim!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com