VERIFIABLE VIRTUALIZED STORAGE PORT ASSIGNMENTS FOR VIRTUAL MACHINES

[0001] The present invention is co-pending with and is a Continuation-In Part of U.S. application Ser. No. 11/583,667 entitled “Identity Controlled Data Center,” filed on Oct. 19, 2006; the disclosure of which is incorporated by reference herein.

[0002] The invention relates generally to security and more particularly to techniques for verifiable virtualized storage port assignments in virtual machines.

[0003] Increasingly enterprises are attempting to utilize existing technology to conduct business and affairs in a distributed and more automated manner. For example, enterprises are now capable of deploying software services to remote facilities or customers over the Internet.

[0004] One technique for achieving this is the creation of a virtual machine (VM). A VM is a software abstracted layer that is partitioned within a physical machine environment to create and establish a different and dual environment from that which is associated with the physical machine. A single machine can have multiple VM's. Essentially, a VM acts as an independent environment and machine that is different from the physical machine on which it processes.

[0005] Yet, establishing a VM is not an automated exercise by any means and involves a variety of configuration settings. The VM has to be self-sustaining as an independent logical machine that actually uses the physical resources of a different machine. So, proper configuration of services within the VM is vital.

[0006] Another concern is a storage system used in the target physical environment for the VM. Specifically, modern storage systems largely exist to provide storage redundancy, flexible storage density, flexible storage assignment, storage access security, flexible storage sizing, etc. Yet, it has become increasingly difficult for modern data centers to host critical enterprise data on disk subsystems, which may be associated with only one computer. This situation is compounded by the pressure to consolidate execution environments in the data center and to use those environments more effectively.

[0007] Typically, a storage device includes a single physical port where access is obtained to the storage device. That port has to be used by the services of a VM if external storage beyond local direct-attached storage is to be used with the VM, which is necessary for VM's that have persistent data. To permit this, the VM or VM services have to include another application that provides access to the storage device and the VM services have to be pre-configured to interact with that application or the VM services have to be pre-configured to directly know and access the proper storage port. Additionally, there is little to no security that is capable of being applied to the port access. So, a VM service with access to a storage port can access the storage even when that VM service may be a rogue service with malicious designs. In fact, there is little to no security applied at the storage port.

[0008] Consequently, establishing VM's is a complicated exercise that lacks a substantial amount of security. Thus, what is needed is a mechanism, which allows for verifiable and flexible storage port assignments within virtual machines.

[0009] In various embodiments, techniques for verifiable virtualized storage port assignments in virtual machines are provided. More specifically, and in an embodiment, a method is provided for defining a virtual distribution associated with a virtual machine. Control data is established for a virtual distribution that is to be subsequently initiated as a virtual machine within a target physical processing environment and a target physical machine. The control data identifies processor and memory resources and a virtual distribution identity acquired to initially verify the virtual machine. Next, storage data is defined for the virtual distribution to identify a port to communicate with physical storage on the target physical processing environment that the processing and memory resources use within the virtual machine. The storage data is also used to identify a storage designator to assist in verifying the port before the virtual machine is operational in the target physical processing environment. Finally, an identity service is used for signing the storage data to bind it with the control data of the virtual distribution.

[0016] A “resource” includes a user, content, a processing device, a node, a service, an application, a system, a directory, a data store, groups of users, combinations of these things, etc. The term “service” and “application” may be used interchangeably herein and refer to a type of software resource that includes instructions, which when executed by a machine performs operations that change the state of the machine and that may produce output.

[0017] The term “remote” is used relatively herein. In other words, when the term “remote” is used as an adjective to a noun it is remote or external to some other entity being referenced within the context of the modified noun. So, as an example: a remote application to a service means that the remote application is external to a local environment and local network associated with the service. In other contexts, the service may be viewed as being remote to the application when it is expressed as: a remote service to an application. Within any given context herein, the term remote is used consistently to identify what entity is in fact remote to what other entity.

[0018] A “processing environment” refers to one or more physical processing devices organized within a local network. For example, several computers connected via a local area network (LAN) may collectively be viewed as a processing environment. The processing environment also refers to software configurations of the physical processing devices, such as but not limited to operating system, file system, directory service, etc. The phrase “processing environment” may be used synonymously herein with the phrase “physical processing environment when that phrase is not preceded by the term “virtual.”

[0019] A “virtual processing environment” refers to a software constructed sub processing environment that is carved out from or superimposed on a portion of a physical processing environment. A single physical processing environment can have a plurality of different or cloned “virtual processing environments.”

[0020] The processing environments (physical and virtual) as used herein are configured to participate in a virtualized data center. A “virtualized data center” refers to a platform or environment for executing one or more similar services or applications. For example, an enterprise may deploy a suite of services for use, some of the service may be related to administration, audit tracking, security, maintenance, etc. of other ones of the deployed services. Thus, the platform or environment can include a variety of services, some of which may share features and some of which may be independent of the other services.

[0021] An “identity service” refers to a special type of service that is designed to manage and supply authentication services and authentication information for resources. So, an identity service may authenticate a given resource for access to a variety of local and external services being managed by that identity service. A single resource may have multiple identity services. In addition the identity service itself may be viewed as a type of resource. In this manner, identity service may authenticate and establish trust with one another viewing one another as specific type of resource.

[0022] According to an embodiment, some example identity services are described in “Techniques for Dynamically Establishing and Managing Authentication and Trust Relationships,” filed on Jan. 27, 2004, and having the U.S. Ser. No. 10/765,523; “Techniques for Establishing and Managing a Distributed Credential Store,” filed on Jan. 29, 2004, and having the U.S. Ser. No. 10/767,884; and “Techniques for Establishing and Managing Trust Relationships,” filed on Feb. 3, 2004, and having the U.S. Ser. No. 10/770,677; all of which are commonly assigned to Novell, Inc., of Provo, Utah and the disclosures of which are incorporated by reference herein.

[0023] An identity service may also provide single sign-on services to a resource. That is, a resource may sign-on to an identity service and acquire identities and credentials to access a variety of other services or resources. In some cases, the identity service is modified or enhanced to perform some of the teachings presented herein and below.

[0024] A resource is recognized via an “identity.” An identity is authenticated via various techniques (e.g., challenge and response interaction, cookies, assertions, etc.) that use various identifying information (e.g., identifiers with passwords, biometric data, hardware specific data, digital certificates, digital signatures, etc.). A “true identity” is one that is unique to a resource across any context that the resource may engage in over a network (e.g., Internet, Intranet, etc.). However, each resource may have and manage a variety of identities, where each of these identities may only be unique within a given context (given service interaction, given processing environment, given virtual processing environment, etc.).

[0025] The identity may also be a special type of identity that the resource assumes for a given context. For example, the identity may be a “crafted identity” or a “semantic identity.” An example for creating and using crafted identities may be found in U.S. patent application Ser. No. 11/225,993; entitled “Crafted Identities;” filed on Sep. 14, 2005; and the disclosure of which is incorporated by reference herein. An example for creating and using semantic identities may be found in U.S. patent application Ser. No. 11/261,970; entitled “Semantic Identities;” filed on Oct. 28, 2005; and the disclosure of which is incorporated by reference herein.

[0026] A “temporary access token” as used herein refers to a temporary identity supplied to a resource for temporary use until a more permanent identity can be established. Furthermore, as used herein a “service provider” (SP) refers to a special type of service or resource that utilizes identities vended by a trusted identity service on behalf of other resources.

[0027] An “orchestration service” is another specialized resource or service that provides a mechanism for orchestrating the deployment, cloning, moving, terminating, etc. of virtual processing environments included within a physical processing environment.

[0028] An example of a virtualized data center that is identity based and provides increased security beyond what has been known in conventional approaches may be found in U.S. application Ser. No. 11/583,667 entitled “Identity Controlled Data Center,” filed on Oct. 19, 2006; the disclosure of which is incorporated by reference herein.

[0029] Embodiments of the present invention are improvements to the “Identity Controlled Data Center,” which provide for verifiable virtualized storage port assignments within virtual machines.

[0030] A “virtual machine” (VM) may be viewed as a virtual processing environment discussed and described above. The VM is a logical machine that is independent of its physical process environment or physical machine. It may include its own operating system (OS), its own file system (FS), its own directory services, etc., which may each be different from the physical processing environment.

[0031] A VM may also be referred to herein as a “virtual distribution.” Similarly, a physical processing environment may be referred to as a “physical distribution.”

[0032] Techniques presented herein and below may also be integrated with N-Port ID Virtualization (NIPV). This can be done by having the specialized service described herein and below as a Storage Resource Manager interact with NIPV services to acquire a virtualized port assignment for a virtual distribution. The Storage Resource Manager may then be used to verify this virtualized port assignment within a target physical distribution in the manners discussed herein and below.

[0033] Various embodiments of this invention can be implemented in existing network architectures, storage systems, security systems, data centers, and/or communication devices. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® network, proxy server products, email products, operating system products, data center products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.

[0034] Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, devices, systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.

[0035] It is within this context, that various embodiments of the invention are now presented with reference to the FIGS. 1-6.

[0036] FIG. 1 is a diagram of a method 100 for defining a virtual distribution associated with a virtual machine (VM), according to an example embodiment. The method 100 (hereinafter “VM packaging service”) is implemented as instructions in a machine-accessible and readable medium. The instructions when executed by a machine perform the processing depicted in FIG. 1. The VM packaging service is also operational over and processes within a network. The network may be wired, wireless, or a combination of wired and wireless.

[0037] At 110, the VM packaging service establishes control data for a virtual distribution (VD) that is to be subsequently initiated as a VM within a target physical processing environment (PE) and physical machine. The control data can include a variety of information that is relevant to the PE, such as but not limited to processor and memory resources and a VD identity, which is used by the PE to verify the VM.

[0038] The Identity Controlled Data Center techniques (pending U.S. application incorporated by reference above and from which this disclosure builds upon) provide a variety of mechanisms in which an orchestrator and remote identity service dynamically interact with and authenticate a PE to acquire operating data. In an embodiment, this operating data may be viewed as the control data. Additionally, the manner in which the VD identity is established or temporary access token is supplied to the control data is described in detail with the Identity Controlled Data Center Techniques. So, the PE (target physical processing environment or target physical distribution) is selected for a VD and control data is established and that control data includes an initial and temporary VD identity.

[0039] At 120, the VM packaging also augments the control data by defining storage data for the VD. The storage data identifies a storage port that is to be used for communication with physical storage in the PE. Furthermore, the control data defined processor and memory resources within the VM can use the storage port for access to physical storage once initiated within the PE.

[0040] The storage data also identifies a storage designator. A storage designator is a special type of service, such as the service provider discussed in the Identity Controlled Data Center techniques, which processes when the VD is initiated as a VM in the PE. The storage designator verifies the storage port in the PE before the VM is initiated. This is discussed in greater detail below with reference to the method 300 of the FIG. 3. In some cases, the storage designator may be a storage resource manager (SRM) discussed in greater detail herein and below. The SRM interacts with the physical storage and storage managers to supply port access to the VM for physical storage of the PE.

[0041] In an embodiment, at 121, the VM packaging service may enlist a SRM to identify the storage port for use in the storage data, this port may be resolved in response to one or more specifications or policies that a user defines. Accordingly, at 122, the VM packaging service can receive the port from the SRM and that port may in some cases be associated with multiple storage volumes and storage managers on the PE.

[0042] In still more situations, at 123, the VM packaging service may include a variety of other information in the storage data. For example, the storage data may include an encryption key or an encryption token that can be used to encrypt storage within the VM on the PE and its physical storage when the VD is initiated as the VM. The storage data may also include persistence specifications. Persistence specifications may identify situations in which storage accessed and modified by the VM during its life-cycle is to survive or persist when the VM terminates and ceases to exist. So, the physical storage used by the VM via the storage port and the SRM may be cleared or made available for other uses after the VM terminates (non persistent) or it may persist after the VM terminates for other VM's or the PE to use as it was left by the terminated VM.

[0043] At 130, the VM packaging service enlists an identity service to sign the storage data. This binds the storage data and the storage port with the control data of the VD. Example identity services were discussed and incorporated by reference above. The signature provides added security to the storage port and its other related configuration information, such as the storage designator, the encryption key, and/or the persistence specifications.

[0044] According to an embodiment, at 140, the VM packaging service may store the control data and the signed storage data in a data repository. This data is associated with the VD identity and may be searched and retrieved from the repository. A collection of VD's may be established for particular systems on particular PE's and housed in the repository for subsequent use.

[0045] In another situation, at 150, the VM packaging service adds image data to the VD. The image data includes imaged versions of such things as a desired operating system (OS), desired files system (FS), desired directory services, the storage designator, and other services that are used on the PE with the VD when the VD is initiated as a VM on the PE. These services are preconfigured and imaged, such that when re-imaged they become available and execute on the PE as the VM defined by the VD. At 151, the control data, the signed storage data, and the image data may also be signed by the identity service or another trusted entity and assembled as a configuration definition for the VD. The signature may be verified when the VM associated with the VD is initiated on the PE.

[0046] The VM packaging service provides a mechanism that builds on the Identity Controlled Data Center techniques for defining a VD that can subsequently be verified on a target PE before a VM representing the VD is established and initiated on the PE. The VM packaging service augments the Identity Controlled Data Center techniques by establishing verifiable virtualized storage ports for use in the configuration information of the VD being defined. An example, architecture and additional discussion for the VM packaging service is described below with reference to the FIG. 2. Additionally, discussion on how the VD is instantiated and verified on a target PE is described in detail below with reference to the method 300 of the FIG. 3.

[0047] FIG. 2 is a diagram of example interactions for an architecture associated with the method depicted in FIG. 1, according to an example embodiment. The diagram includes a variety of resources and interactions that these resources have with one another for purposes of initially authenticating a target physical processing environment (physical distribution) and setting it up for subsequent deployment of virtual processing environments (virtual distributions) and applications that may execute within those virtual distributions. The diagram also illustrates how a virtualized port assignment may be securely packaged and included with the virtual distributions.

[0048] Initially, an orchestrator (described with the Identity Controlled Data Center techniques) is used by data center personnel to manage a virtualized data center. One of the tasks of the orchestrator is the initial definition of a VD and the maintenance of that VD afterward. This can be achieved via link A in FIG. 2.

[0049] The Define VM task in FIG. 2 may be viewed as the VM packaging service discussed above with reference to the method 100 of the FIG. 1. The Define VM task proceeds to build/maintain a VD configuration using link B. The configuration may include four main components: control, store, image, and signature.

[0050] The control section provides the configuration and policy statements that can be used when instantiating the VD as a VM on the PE to make sure that the correct resources are assigned and made available by the PE (physical distribution). Again, this is discussed in greater detail with the Identity Controlled Data Center techniques. Similarly, the control section includes an VD identity and establishment of that initial VD identity (also described in detail with the Identity Controlled Data Center techniques). The image section provides for the definition of the execution environment for the target PE including the use of a specialized service provider (SP), which is described with the Identity Controlled Data Center techniques. The VDistro Signature is a digital signature that protects the configuration data for the VD from being tampered with. VDistro stands for Virtual Distribution in the FIG. 2.

[0051] The store section is describes in detail above with reference to the VM packaging service represented by the method 100 of the FIG. 1. The store section provides for the definition of storage restrictions and requirements that can be used by the VD. The mundane assignment of scratch storage local to the PE is not discussed. However, there the need to specify storage in terms of access to shared storage is described with reference to the virtualized storage port included in the VD store section.

[0052] The VD's access to one or more SRM's is defined via specifications from a user that defines the VD initially via link C in the FIG. 2. The SRM interrogates the various storage managers via link D in the FIG. 2. The storage managers manage the physical shared storage via E. The end result is that the SRM can provide and acquire a reference port to the needed physical storage that can be passed back to the Define VM task via C.

[0053] The storage definition is then assembled and signed by an Identity Management Service (IS) via link F of the FIG. 2 so that it can be bound to the specific VD. As an example, “Store1” is seen in the configuration data of the FIG. 2 that it holds a configuration that defines a storage designator (e.g., name in the SRM namespace), storage port, key (for encrypted storage management—the key may actually be a token or SAML assertion that allows the identity service (IS) to provide the actual key), persistence specifications (should the storage be persisted beyond the execution of the VD), etc.

[0054] Finally, the VD can be signed, perhaps by the identity service (IS), and stored along with other VD's via link G in the FIG. 2.

[0055] FIG. 3 is a diagram of method 300 for remotely verifying and establishing a virtual machine within a physical processing environment, according to an example embodiment. The method 300 (hereinafter “VM initiation service” is implemented in a machine-accessible and readable medium as instructions. The instructions when executed by a machine perform the processing depicted in the FIG. 3. Moreover, the VM initiation service is operational over a network, and the network may be wired, wireless, or a combination of wired and wireless.

[0056] The VM initiation service complements and adds features and functions to what was described above with respect to the method 100 of the FIG. 1. The VM initiation service is also used to deploy, instantiate, clone, move, terminate, etc. virtual processing environments (VM's or virtual distributions) in authenticated and trusted physical processing environments (physical distributions or PE's).

[0057] At 310, the VM initiation service receives a request to initiate a VD as a VM within a physical processing environment on a physical machine (PE). Again, an orchestration service may be used to initiate the request that is received by the VM initiation service. Policy may drive when the orchestrator sends or raises the request. Moreover, the orchestrator can acquire the specific VD from a data repository as discussed above with reference to the FIGS. 1 and 2.

[0058] At 320, the VM initiation service verifies a signature associated with configuration data that defines the VM. The configuration data was defined above in detail with reference to the FIGS. 1 and 2. The signature may be associated with an external or remote identity service that assisted in creating the configuration data and establishing an initial identity for the VD.

[0059] At 330, the VM initiation service acquires a permanent VM identity using a temporary identity housed in the configuration data via interactions with one or more identity services. Examples of this are presented in detail with the Identity Controlled Data Center techniques. In some cases, the temporary identity is handled by a special service provider (SP) that contacts a local identity service on the PE and supplies the temporary identity. That local identity service contacts a remote identity service to verify the temporary identity and then the local identity service provides a unique identity for the VM within the PE.

[0060] At 340, the VM initiation service contacts a storage resource manager (SRM) or a storage designator to verify a storage port assignment for storage in the VM and defined in the configuration data. The reference to the SRM may be included in the configuration data as well or may be resolved by the SP that is identified as the storage designator in the configuration data. The SRM contacts storage managers and verifies the port assignment. This verifies the previously assigned virtualized storage port before the VM is initiated on the PE. So, the virtualized storage port is verifiable in the PE via the SRM.

[0061] At 350, the VM initiation service starts services identified in the configuration data for the VM within the PE when the signature and the storage port are verified. It is noted that at any point in which the signature, the identity of the VM, and the storage port are not verified the VM will not be initiated and the services will not be started. Logging and reporting may be used as well as audit compliance techniques for the entire process described in the FIG. 3.

[0062] According to an embodiment, at 360, the VM initiation service communicates the storage port to a PE driver service for purposes of establishing a communication path from the VM to the physical storage of the PE. This can be done via the SRM, such that services issuing storage commands are redirected to the SRM and the SRM forwards to the PE driver to be sent to the proper storage manager and storage port to access the physical storage.

[0063] In some cases, at 370, the VM initiation service may also receive a move request. The move request is associated with moving a VD to a different PE. Thus, the VM initiation service can notify the SRM to stop all VM access to the storage port. Of course pending writes or volatile operations may be permitted to flush from memory to the storage. The VM initiation service also modifies the configuration data for a subsequent VD to a different PE.

[0064] Similarly, at 380, the VM initiation service may receive a copy request. The copy request is associated with copying the VD as a new and second VD on the same PE. To do this, the VM initiation service notifies the SRM to permit the second VM to access the storage port, when policy permits. That is, policy may not allow multiple VM's to simultaneously access the same storage port. Assuming policy permits, the VM initiation service copies the configuration data for the VM and acquires a second identity from the second VM for use in the second VM and then starts the second VM on the PE.

[0065] It may also be the case, at 390 that the VM initiation service receives a termination request. A termination request is to stop the VM within the PE. In response to this termination request, the VM initiation service notifies the SRM to stop all VM access to the storage port. Again, pending volatile operations may be permitted to flush to the physical storage. Next, the services are stopped for the VM.

[0066] According to an embodiment, at 391, the VM initiation service may maintain storage that was accessed by the VM when persistence specifications existed in the configuration data indicating that storage was to remain persistent beyond the life of the VM or after VM stoppage. However, at 392, the VM initiation service may clear or make the storage available for use when persistence specifications do not exist in the configuration data after VM stoppage.

[0067] It is now appreciated how a virtualized storage port for a VM may be established and verified with the instantiation of a VD. The definition of the VD and storage port was defined above with reference to the FIGS. 1 and 2. FIG. 4 now describes an example architecture for achieving the processing associated with the VM initiation service represented by the FIG. 3.

[0068] FIG. 4 is a diagram of example interactions for an architecture associated with the methods depicted in FIGS. 1 and 3, according to an example embodiment. The diagram includes a variety of resources discussed with the methods 100 and 300 of the FIGS. 1 and 3, respectively. Moreover, the diagram illustrated interactions that there resources have with one another to establish authentication and trust with one another via identity creation, management, and distribution. The resulting identity-based architecture permits virtual data centers to be dynamically distributed, cloned, moved, terminated, etc. within a physical processing environment and permits virtualized storage ports to be assigned, authenticated, and instantiated for VM's (virtual distributions).

[0069] The rectangle box on the right includes a variety of other smaller rectangles. The V-Distro—X represents a particular VM for a VD identified by the configuration data X (represented by the upside down triangle X. Similarly, the V-Distro—Y represents a particular VM for a VD identified by the configuration data Y (represented by the upside down triangle Y. The P-Distro represents the PE from which the VD's are layered on top of. The P-Distro includes its own Identity Service (IS), physical storage driver and host processes. Each VD includes a specialized service provider SP (discussed in detail with the Identity Controlled Data Center techniques), which knows how to contact the local IS of the PE and contact the SRM and a remote identity service (also labeled IS in FIG. 4). With this background information, FIG. 4 is now discussed in greater detail.

[0070] An orchestrator access a library of VD's via link A in the FIG. 4 and initiates the process to start, clone, move, copy a particular VD within a PE as a VM via links B and C. The operations initiate the VD in the PE as provided with the Identity Controlled Data Center techniques. Specifically, the link flows D, E, and F reference processing which serves to instantiate the VD on the PE according to policy and identity assignment and authentication as discussed with the Identity Controlled Data Center techniques.

[0071] The SP (or other service cooperating with the SP/IS trust model) to provide a port/reference assignment to the SRM via G, which results in validation via H and J. If all is well and the port reference can be honored, the disposition is passed back via G. This then allows the SP (or other service cooperating with the SP/IS trust model) to communicate with the PE to provide the port reference for access to the shared storage (such as via paths from the PE driver to the physical storage managers (not labeled specifically in the FIG. 4)).

[0072] If the VD is to be moved, the SP (or other service cooperating with the SP/IS trust model) notifies the SRM that the port is being moved and to stop allowing access via G. The image of the VD is then assembled and moved to another PE via the orchestrator and the process described above is used to re-instantiate the port for use by the new VD on the new PE.

[0073] If the VD is to be copied then this same process takes place but the SRM is notified that another port will be instantiated and to expect the additional port access. Note that this mechanism is valid when the storage configuration specifies that multiple uses of the port is to be allowed and that the port request can be honored by the SRM (e.g., its policy may forbid multiple uses of certain types of storage ports, etc.).

[0074] Termination of the VD is similar to a move except that the image of the VD is not re-instantiated.

[0075] It is because of the trust model established with the Identity Controlled Data Center techniques and the interaction of identity with the identity services and other components of the virtualized data center that each access request is secure and bound by policy. Note also that if the port reference is for scratch or temporary storage on the shared storage mechanism that this too is controlled and managed by policy, including persistence of the scratch or temporary storage allocation.

[0076] FIG. 5 is a diagram of a virtual machine defining system 500, according to an example embodiment. The virtual machine defining system 500 is implemented as instructions on or within a machine-accessible and readable medium. The instructions when executed by a machine perform the processing depicted in the method 100 of the FIG. 1. The virtual machine defining system 500 is operational over a network that may be wired, wireless, or a combination of wired and wireless.

[0077] The virtual machine defining system 500 includes a storage resource manager (SRM) 501 and a virtual machine definer (VMD) 502. The virtual machine defining system 500 may also include one or more of the following: an orchestrator 503, an identity service 504, and one or more storage managers 505. Each of these and there interactions with one another will now be discussed in turn.

[0078] The SRM 501 is implemented in a machine-accessible and readable medium and is to process on a machine. The SRM 501 is called initially during a VM defining or configuration process to provide a valid storage reference port to shared storage for a VM. The SRM 501 or other instances of the SRM 501 may be subsequently called when the VM is being instantiated to verify the virtualized storage reference port and to establish a legitimate communication path between the VM and the shared physical storage via physical storage managers and/or drivers on the PE. Example processing associated with the SRM 501 was described in detail above with reference to the FIGS. 1-4. The SRM 501 provides a mechanism for pre-assigning shared storage port references to a VD or VM and the mechanism for verifying that shared storage port reference when the VD is instantiated as a VM on a PE.

[0079] The VMD 502 is implemented in a machine-accessible and readable medium and is to process on a machine. The VMD 502 was described in detail above with reference to the FIGS. 1 and 2. The VMD 502 interacts with a PE; perhaps an orchestrator 503 and identity service 504; and the SRM 501 for purposes of initially defining configuration data for a VD. The configuration data includes control data, storage data, image data, and a signature of the identity service 504. The storage data is acquired via the SRM 501 and may include other information beyond just the shared storage port assignment reference, such as encryption keys or tokens and persistence specifications. The storage data also includes a reference to a storage designator in the PE, such as a SP or the SRM 501. The VD's created as configuration data by the VMD 502 may also be stored in a repository or library for subsequent use.

[0080] In some cases, the virtual machine defining system 500 also includes an orchestrator 503. The orchestrator 503 is implemented in a machine-accessible and readable medium and is to process on a machine. The orchestrator 503 acquires VD or starts the process or defining, cloning, moving, copying, and/or terminating a VD. The orchestrator 503 may also be used to manage VD after initial definition. Example features and interactions of the orchestrator 503 were provided above with reference to the FIGS. 2 and 4.

[0081] In yet more cases, the virtual machine defining system 500 includes an identity service 504. The identity service 504 is implemented in a machine-accessible and readable medium and is to process on a machine. Examples of the identity service 504 was described in detail above and incorporated by reference above. The identity service 504 provides the trust and management or identities and provides signatures to ensure that each access is trusted and secure. Interactions of the identity service 504 with other components (including local PE identity services) and the VMD 502 were described in detail above with reference to the FIGS. 1-4.

[0082] In another situation, the virtual machine defining system 500 includes one or more storage managers 505. The storage managers 505 are implemented in a machine-accessible and readable medium and is to process on a machine. The storage managers 505 interact with the SRM 501 to provide a valid storage reference port to shared storage. The SRM 501 interacts with the storage managers 505 to permit a VM (instantiated VD on a PE) to access shared storage via a storage reference port included and verified by the SRM 501 in the configuration data from the VD.

[0083] FIG. 6 is a diagram a virtual machine verifying and initiating system 600, according to an example embodiment. The virtual machine verifying and initiating system 600 is implemented as instructions on or within a machine-accessible and readable medium. The instructions when executed by one or more machines perform processing depicted with respect to the method 300 of the FIG. 1. The virtual machine verifying and initiating system 600 is also operational over a network and the network may be wired, wireless, or a combination of wired and wireless.

[0084] The virtual machine verifying and initiating system 600 includes virtual machine initiation service 601 and a storage resource manager (SRM) 602. In some cases, the virtual machine verifying and initiating system 600 may also include one or more identity services 603 and 604 and/or one or more storage managers 605. Each of these will now be discussed in turn.

[0085] The virtual machine initiation service 601 is implemented in a machine-accessible and readable medium and is to process on a machine. The physical machine or environment that a virtual distribution or VM is to be installed on. The virtual machine initiation service 601 interacts with a local identity service 603 and a remote identity service 604. The manner in which this interaction occurs is described in detail with the Identity Controlled Data Center techniques.

[0086] The virtual machine initiation service 601 may also be called by an orchestrator to instantiate a VD, move a VD, clone or copy a VD, terminate a VD, etc.

[0087] The virtual machine initiation service 601 acquires an identity for the VD by requesting that a local identity service 603 use a temporary access token or identity included in the configuration data to contact the remote identity service 604 and acquire a permanent unique identity for the VD in the PE. The virtual machine initiation service 601 also interacts with the SRM 602 to verify a storage port included in the configuration data from the VD for use by a VM within the PE via reference to the storage port.

[0088] The virtual machine initiation service 601 is also to start services within the PE for a VM when the VD is instantiated or verified in terms of identity and in terms of the storage port assignment. Imaged versions of the services are provided with the configuration data or are obtainable via information included in the configuration data.

[0089] The SRM 602 is implemented in a machine-accessible and readable medium and is to process on a machine, which may or may not be the physical machine that the VM is initiated on. The SRM 602 interacts with the virtual machine initiation service 601, the instantiated VD as a particular VM, and one or more storage managers 605. The SRM 602 verifies configuration data supplied shared storage port references and provides a conduit through which storage commands from a processing VM may be properly forwarded and handled by the proper storage managers 605.

[0090] In some cases the virtual machine verifying and initiating system 600 also includes one or more identity services 603 and 604. Each identity service 603 and 604 is implemented in a machine-accessible and readable medium and each is to process in a different environment and on a different machine. A local identity service 603 is in a trusted and secure relationship with a remote identity service 604. The local identity service 603 can validate a temporary identity of a VD via the remote identity service 604 and can supply a permanent unique identity to the VD within the context of the PE. The remote identity service 604 provides validation, signature, and temporary identity services to the local identity service 603 and in some cases the SP's (described above).

[0091] Additionally, the virtual machine verifying and initiating system 600 may also include one or more storage managers 605. Each storage manager 605 is implemented in a machine-accessible and readable medium and is to process on one or more machines, some if which may or may not be the physical machine that the VM is initiated on. The storage managers 605 know how to access the physical shared storage and how to acquire a particular storage port for contacting physical storage. The storage managers 605 interact with the SRM 602 to supply port references and to supply operations to the physical storage.

[0092] The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0093] The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0094] In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.