Difference between revisions of "Pci resource management"
| Line 2: | Line 2: | ||
a) Same PCI had different Objects, one in the stats and another in the instance | a) Same PCI had different Objects, one in the stats and another in the instance | ||
b) when RESIZE secondary host get other instances Objects | b) when RESIZE secondary host get other instances Objects | ||
| + | c) pci device is 'identifiable': 2 pci device not mean any 2 pci device, need to be the same 2 devices, in the resize processing. | ||
Resize: | Resize: | ||
Latest revision as of 07:14, 30 January 2015
a) Same PCI had different Objects, one in the stats and another in the instance
b) when RESIZE secondary host get other instances Objects
c) pci device is 'identifiable': 2 pci device not mean any 2 pci device, need to be the same 2 devices, in the resize processing.
Resize:
-> new host claim -> old host stop (instance going to new HOST)-> new host starting new instance
Confirm:
new machine call source machines’s drop_resize_claim ( a new resource tracker been setting up)
Aborting:
new: stop new instance, drop claim -- > old: reverting old status and stating machine
- problem 1:
'claimed' status must be used to keep old device on source machine. we use node_id, not hostname, so use claimed status to keep out other machine's device out. solution A: get compute node from instance's hostname --> get compute_node_id risk: always reading DB can not cache. 方法2: keep claimed status
- problem 2:
multiple objects for same db instance of pci devices must operating the local dev(otherwise miss the save process)
