[Libvirt-cim] [RFC] override CreateSnapshot extrinsic

[Dan Smith]

JF> Some tools will parse the class info and format gui based on
JF> qualifiers it finds.  In the case of CreateSnapshot, such tools will
JF> not display the vendor additions unless we override the method and
JF> describe the additions.

Agreed.

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.  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.

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.

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.

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.  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.

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?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080807/e5f372dc/attachment.sig>