Methods for transferring reserves when moving virtual machines across systems
US-9852154-B2 · Dec 26, 2017 · US
US9984097B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-9984097-B2 |
| Application number | US-94387410-A |
| Country | US |
| Kind code | B2 |
| Filing date | Nov 10, 2010 |
| Priority date | Nov 10, 2010 |
| Publication date | May 29, 2018 |
| Grant date | May 29, 2018 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
According to one embodiment, a host system includes logic adapted for receiving device information from a source system, logic adapted for building a virtual device based at least in part on the received device information, logic adapted for transferring a reserve of a storage device to the host system and/or receiving results of transferring the reserve to the host system, logic adapted for determining if the reserve is held by the host system, logic adapted for recording the reserve if the reserve is held by the host system, and logic adapted for sending a notification that the reserve is not held by the host system if the reserve is not held by the host system. Other systems and computer program products are also described according to various embodiments.
Opening claim text (preview).
What is claimed is: 1. A host system, comprising: a hardware processor; a memory; and logic stored in the memory and executable by the processor, the logic being configured to: receive device information about a first device, the device information being received by a host system from a source system; build a virtual device on the host system that is equivalent to a virtual device on the source system based at least in part on the received device information; set a flag byte in a command input for a new reserve holder specifying whether a push command or a pull command will transfer a reserve of the first device, wherein the new reserve holder is the host system; initiate, using the host system, transfer of the reserve of the first device from the source system to the host system by sending an indication to the source system that the virtual device build is complete in response to completion of the virtual device build, wherein the reserve of the first device is transferred using a synchronous push command at the source system, the synchronous push command forcing a response that indicates whether the push command was successful or unsuccessful, wherein the synchronous push command comprises: retrieving a path group identifier (PGID) for each of: an invoker system, a reserve holder system, and the command input for the new reserve holder; determining whether the PGID of the reserve holder system is the same as the PGID of the invoker system; and in response to a determination that the PGID of the reserve holder system is the same as the PGID of the invoker system: setting the PGID of the reserve holder system to the PGID of the command input for the new reserve holder; and sending a notification to the invoker system that transferring the reserve was successful; receive results from the source system at the host system of transferring the reserve of the first device to the host system indicating a successful transfer in response to a determination that the synchronous push command was successful and indicating an unsuccessful transfer in response to a determination that the synchronous push command was unsuccessful; record, in response to receiving the results, the reserve in response to a determination that a status check on the reserve indicates that the reserve is held by the host system; and send a notification that the reserve is not held by the host system in response to a determination that the status check on the reserve indicates that the reserve is not held by the host system. 2. The host system as recited in claim 1 , wherein the indication that the virtual device build is complete is sent prior to receiving the results from the source system of the transferring of the reserve, wherein the synchronous push command is an unconditional reserve command issued by the source system to hold the reserve for the host system, wherein the source system is the invoker system the reserve holder system, wherein the flag byte in the command input specifies that the synchronous push command will transfer the reserve, and wherein the logic is further configured to: perform a status check periodically to determine whether the reserve is available for transfer to the host system; delay the synchronous push command until the source system determines that the reserve is available for transferring to the host system; receive a release command for the reserve; set the reserve to not held by any system thereby forcing any system which currently holds the reserve to release the reserve from being held; perform a status check to determine whether any system has issued a pending reserve; in response to a determination that no reserves are pending, complete the release command; in response to a determination that reserves are pending: retrieve a PGID of the system which issued a next pending reserve; set the reserve holder PGID to the PGID of the system which issued the next pending reserve; and complete the release command. 3. The host system as recited in claim 1 , wherein the logic is further configured to: delay the synchronous push command until the source system determines that the reserve is available for transferring to the host system; and perform a status check periodically to determine whether the reserve is available for transfer to the host system, wherein the source system is the invoker system and the reserve holder system. 4. The host system as recited in claim 1 , wherein the synchronous push command is an unconditional reserve command issued by the source system to hold the reserve for the host system. 5. The host system as recited in claim 4 , wherein the logic is further configured to delay the synchronous push command until the source system determines that the reserve is available for transferring to the host system. 6. The host system as recited in claim 1 , wherein the logic is further configured to delay the synchronous push command until the source system determines that the reserve is available for transferring to the host system. 7. The host system as recited in claim 6 , wherein the logic is further configured to perform a status check periodically to determine whether the reserve is available for transfer to the host system. 8. A source system, comprising: a hardware processor; a memory; and logic stored in the memory and executable by the processor, the logic being configured to: create a reserve of a first device; send device information about the first device to a target system; receive an indication that a virtual device build is complete from the target system; set a flag byte in a command input for a new reserve holder specifying whether a push command or a pull command will transfer the reserve of the first device, wherein the new reserve holder is the target system; perform a status check periodically to determine whether the reserve is available for transfer to the target system; transfer the reserve of the first device from the source system to the target system using a synchronous push command at the source system in response to receiving the indication that the virtual device build is complete, the synchronous push command forcing results to be sent from the source system to the target system indicating whether the push command was successful or unsuccessful, the synchronous push command comprising: retrieving a path group identifier (PGID) for each of: an invoker system, a reserve holder system, and the command input for the new reserve holder; determining whether the PGID of the reserve holder system is the same as the PGID of the invoker system; and in response to a determination that the PGID of the reserve holder system is the same as the PGID of the invoker system, setting the PGID of the reserve holder system to the PGID of the command input for the new reserve holder and sending a notification to the invoker system that transferring the reserve was successful; delay the synchronous push command until the source system determines that the reserve is available for transferring to the target system; send the results of the transferring of the reserve from the source system to the target system indicating a successful transfer in response to a determination that the synchronous push command was successful; send the results of the transferring of the reserve from the source system to the target system indicating an unsuccessful transfer in response to a determination that the synchronous push command was unsuccessful; and receive a notification that the reserve is not held by the target system in response to a status check on the reserve performed by the target system indicating that the reserve is not held by the target system. 9. The source syst
Physics · mapped topic
Virtual file systems · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.