[Libvirt-cim] [RFC] override CreateSnapshot extrinsic

[Jim Fehlig]

Dan Smith wrote:
> JF> While on the subject, I would like to understand the usefulness of
> JF> SnapshotType 32768.  This type will save the vm's memory state and
> JF> subsequently restore the vm.  IMO applying this memory snapshot
> JF> later would be quite dangerous.  The vm has since been running and
> JF> the disk state will be quite different from when the memory snapshot
> JF> was taken.  Does this make sense or am I not thinking clearly :-)?
>
> That's true, it's not useful (or safe) to do a restore from it again,
> once the guest has been restored once.  However, if you're looking to
> get the memory snapshot for forensic purposes, you would not care to be
> able to restore from it again.

Right, that's a valid use case.

> Perhaps we should use a different
> filename in the case of a save-and-restore snapshot so that we don't
> confuse our own logic into thinking that the domain has a valid save
> image.
>   

Agreed.  Sounds like a good idea.

> JF> Finally, invoking CreateSnapshot with SnapshotType 32769 will save
> JF> the vm and leave it powered off.  Querying EnabledState shows the vm
> JF> Enabled but Offline' (suspended).  According to System
> JF> Virtualization Profile, one should be able to move a vm in this
> JF> state to Enabled by invoking RSC(Enabled) but doing so results in
> JF> "snapshot exists, apply snapshot" error.  So the behavior diverges
> JF> from the spec IMO.  It seems the current behavior of SnapshotService
> JF> should just be implemented via RSC.  CreateSnapshot -> RSC(Enabled
> JF> but Offline), ApplySnapshot -> RSC(Enabled)
>
> I thought we had discussed this before on IRC, but perhaps it got lost
> in some of the other noise.
>   

We did.  I just felt the need to revisit it after playing with the code :-).

> It seems a little broken to me to have the services cross each other
> with this bit of functionality.  While it may seem trivial right now,
> since we only ever have one snapshot to restore from, I wonder what
> behavior it should have later if we support multiple ones?  Should it
> restore from the most recent?  The oldest?  The snapshot service handles
> this by exposing the snapshots as instances that the caller can
> reference when asking to restore.
>   

Yep, understood.  I think my biggest problem with the SnapshotService is 
that I have a hard time thinking about snapshots that don't include a 
disk component - even more so in the context of multiple snapshots.  
This to me is the usefulness of SnapshotService.  I can happily take 
snapshots (either just disk or disk + memory) and then sometime later 
select one to apply and end up with a functional system.  With multiple, 
memory-only snapshots I think the most recent is all that could be 
safely applied.

> I would expect this to be the desired and sane behavior if it was all
> contained in ComputerSystem, but I don't think it makes sense to
> intermingle the behavior of the snapshot service in this case.

Agreed.

> Perhaps it would have been better to support this by doing a save on
> RSC(suspend) and a restore on RSC(enabled, from suspend) in the first
> place, but we figured that the snapshot service would be more useful in
> the long run.
>   

 From a client's perspective I just think it is cumbersome to use the  
SnapShotService to implement the notion of suspend.  IMO, either the 
providers should support suspend or not.  Currently they don't (as 
indicated in capabilities) but after invoking CreateSnapshot the vm is 
in suspended state - so they kind of do.  Folks here writing client code 
are a little confused by this :-).

> If we specify in the capabilities object that we don't support the
> transition from suspended to enabled, then we're not really breaking the
> spec here, right?
>   

Correct.  And it seems the Virtual System Profile allows for states to 
occur even if the client cannot explicitly move the vm to that state.  
 From note on page 23:

     NOTE State transitions may be observed even if client state 
management as described
     in section 7.6 is not supported. For example, a state transition 
might be initiated by means
     inherent to the virtualization platform, or it might be triggered 
during activation of the
     virtualization platform itself.

So I think it is safe to say that from client's perspective the 
providers don't support the suspended state.  That said, they can 
achieve the same effect by means of {Create,Apply}Snapshot with the 
vendor defined values.

Thanks,
Jim