xen-org/xen-api — pull request #726 by djs55 (2012-07-03 15:59:23+00:00)
Title: CA-83076: avoid xapi and xenopsd both "owning" the Vbd.backend xenopsd f...

...ield

The xapi/xenopsd separatation needs to be strictly as follows:

1. all the static VM metadata (Vm.t, Vbd.t, Vif.t, Pci.t) is owned and
updated by xapi, whenever the user requests it via the XenAPI

2. all the dynamic VM state (Vm.state, Vbd.state, Vif.state, Pci.state)
is owned and updated by xenopsd. Xapi will receive events on this
and update some data in the pool database.

In particular a xenopsd API call (Vbd.insert, Vbd.eject) must not write
any static metadata directly, since this will conflict with parallel
updates from xapi.

Furthermore all dynamic VM state updates from xenopsd need to be "complete"
and not require correlating with static VM state. For example the disk
"backend" which is currently associated with a CDROM must be completely
described in the Vbd.state.

The XenAPI VBD.insert/VBD.eject control flow is now:

1. xapi calls xenopsd with VBD.insert/eject
2. xenopsd performs the xenstore-level operation (including stashing away
the VDI in xenstore)
3. xenopsd generates an event on the VBD
4. xapi receives the VBD event and calls VBD.stat
5. xapi sets VBD.{empty, VDI} in the pool database based on the VBD.stat
results
6. xapi inserts a barrier event to ensure all events are processed

After step (5), a XenAPI event will be generated which will be received
by the event.from in xapi_xenopsd, which will cause xapi to push the
new Vbd.t configuration to xenopsd, ensuring that the insert/eject will
take effect on next reboot.

Signed-off-by: David Scott

Tested by:
1. 100 sequential CDROM insert/ejects to a win7 guest with a background random event generator (couldn't repro the problem with and without the fix unfortunately)
2. manual verification that the "VBD refresh" via cdrommon should still work: I commented out some of the assertions and verified that I could "xe vbd-insert" multiple times and not get an error
3. win7 suspend/resume/migrate preserves the CDROM setting with both "full" and "empty" drives
4. quicktest