Vmware, Inc.

Dilpreet S Bindra

Patrick Tullmann

Carl Alan Waldspurger

Osten Kit Colbert

Min Cai

Ashish K Hanwadikar

Cheng Cheng

Gregory T Harm

Gregory T Harmon

Amit Bose

Exemplary methods, apparatuses, and systems include a first virtual infrastructure manager (VIM) determining that the first VIM is to be an active manager of a plurality of virtual machines running on a plurality of host devices and that a second VIM is to be a standby manager of the plurality of virtual machines. The first VIM selects a first host device from the plurality of host devices to serve as a passive witness node in arbitrating active and standby roles between the first VIM and second VIM. The first host device runs one or more virtual machines and is managed by the active manager. The first VIM selects a first host device by confirming that the first host device is available to each of the first VIM and the second VIM. The first VIM writes a file on the first host device indicating that the first VIM is the active manager.

High availability using dynamic quorum-based arbitration

A method is provided for recovering from an uncorrected memory error located at a memory address as identified by a memory device. A stored hash value for a memory page corresponding to the identified memory address is used to determine the correct data. Because the memory device specifies the location of the corrupted data, and the size of the window where the corruption occurred, the stored hash can be used to verify memory page reconstruction. With the known good part of the data in hand, the hashes of the pages using possible values in place of the corrupted data are calculated. It is expected that there will be a match between the previously stored hash and one of the computed hashes. As long as there is one and only one match, then that value, used in the place of the corrupted data, is the correct value. The corrupt data, once replaced, allows operation of the memory device to continue without needing to interrupt or otherwise affect a system's operation.

Transparent recovery from hardware memory errors

A software component is executed to carry out a task, the task including a subtask. An external function is called to perform the subtask, the external function executing in a separate thread or process. The component receives an observation recorded by the external function, the observation including an identifier of a possible error condition and instance data associated with the possible error condition. The possible error condition being a cause of the failure of the external function to carry out the subtask. If the task cannot be completed, then a new observation is recorded along with the received observation, the new observation being related to a possible error condition of the component, which is a cause of the failure of the component to carry out the task. When the task can be completed despite the failure of the external function, the observation recorded by the external function is cleared.

Error reporting through observation correlation

Growing community of inventors

Hayward, CA, United States of America

Dilpreet S Bindra