Conversation

This resolves a bug where VDIs were reset after migration, because the act of
plugging a VBD will reset the VDI. A corresponding change in the storage
managers moves the reset_leaf call (which resets VDIs) to the SR command
"vdi_epoch_begin", which was recently added to Xapi's SMAPIv2.

This commit just adds the plumbing necessary to call epoch_begin and epoch_end
on VDIs in the storage layer. The corresponding commit in sm.hg adds those
commands to the storage layer, and also moves the reset_leaf call into
vdi_epoch_begin.

This resolves a bug where VDIs were reset after migration, because the act of
plugging a VBD will reset the VDI. A corresponding change in the storage
managers moves the reset_leaf call (which resets VDIs) to the SR command
"vdi_epoch_begin", which was recently added to Xapi's SMAPIv2.
This commit just adds the plumbing necessary to call epoch_begin and epoch_end
on VDIs in the storage layer. The corresponding commit in sm.hg adds those
commands to the storage layer, and also moves the reset_leaf call into
vdi_epoch_begin.
Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>

@andreil has pushed the changesets we depend on into trunk-storage. I recommend that we pull those changesets into trunk-ring3 manually, and then merge this pull request on Monday. After we get a build and BVT from trunk-ring3, we can merge the sm.hg and the xen-api.git changes into the Clearwater branch.

I think VBD_epoch_end needs to be in VM_poweroff and VM_reboot but not VM_shutdown -- if you look at VM_suspend it calls VM_shutdown. Probably we should rename "VM_shutdown" to something more domain-specific to avoid this kind of confusion in future!