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@us.ibm.com