Migrating virtual machines across commonly connected storage providers

Method and system for deploying a virtual machine or attaching a storage volume to a virtual machine (VM). A process obtains information regarding fabrics attached to hosts and storage devices attached to the fabrics and determines whether a VM can be deployed to a host or whether storage volumes can be attached to a VM. In one case, determining that a fabric attached to a host can support a virtual SCSI volume causes migrating a VM to the host and attaching the virtual SCSI volume to the migrated VM. In another case, determining that the fabric attached to a host can support an NPIV volume causes migrating the VM to the host and attaching the NPIV volume to a virtual channel mapped to the fabric attached to the host. If the VM cannot be migrated, then the user is given an indication that the attachment is not possible.

BACKGROUND

The present invention relates to deploying virtual resources, and more specifically, to deploying virtual machines and attaching storage volumes to virtual machines.

A storage connectivity group (SCG) is a logical grouping of resources that can be used to connect storage to virtual machines (VMs) along with the rules to specify how to make the connection. The SCG is associated with sets of fabrics to which physical storage is attached and a set of virtual I/O servers (VIOS), each of which provides IO services to a VM. The sets of fabrics and set of VIOSs are considered storage connectivity candidates for virtual machines during deployment and migration and when new storage is attached to a virtual machine. However, when deploying a VM or attaching a volume to a VM, failure to consider the capabilities of the available fabrics may cause errors in deploying the virtual machine or attaching a volume.

There is a need to improve the ability to deploy virtual machines and to attach new storage to a virtual machine in light of the available fabrics connected to the several host computers so as to avoid errors in deploying the virtual machine or attaching a volume to a virtual machine.

SUMMARY

One embodiment of the present invention includes a method for attaching a storage volume to a virtual machine. The method includes determining from a plurality of storage providers that an attachment of the storage volume to the virtual machine is possible, where each storage provider includes a fabric and a portion of a plurality of storage devices connected to the fabric and the fabric of each storage provider is connected to one or more host computers of a plurality of host computers. The method further includes migrating the virtual machine from a first host computer on which the virtual machine is running to a second host computer to allow the attachment of the storage volume to the virtual machine if migration of the virtual machine is permitted, and attaching the storage volume to the migrated virtual machine.

Other embodiments include a system and a computer program product carrying out one or more aspects of the above method.

One aspect of the embodiments is that it is less likely that an error is encountered when deploying a virtual machine or when attaching a volume to a virtual machine because the properties of fabrics and ports of the fabric are considered in performing the deployment or volume attachment.

DETAILED DESCRIPTION

FIG. 1depicts a block diagram of a system that is representative of an architecture in which embodiments may be implemented. The architecture includes one or more host computers including a first host computer102and a second host computer132. The first host computer102includes hardware122, hypervisor/virtualization software125and one or more client virtual machines (VM)104a-n. The hardware122includes one or more CPUs124, RAM126, a network interface128and a host storage130, such as one or more persistent storage devices. The RAM126stores programs in the form of instructions executed by the one or more CPUs124, which programs may be stored on host storage130and loaded into RAM126from host storage130. Each client VM104a-nincludes a generic virtual SCSI disk106and a virtual Small Computer System Interface (vSCSI)108. The vSCSI disk106is coupled to a Virtual IO Server (VIOS)112via a SCSI channel110and includes one or more generic SCSI Logical Unit Numbers (LUNs)114,116and one or more host bus adapters (HBA)118,120, where a generic SCSI LUN is an allocation of block storage from a pool of block storage available to the VIOS. The VIOS112provides virtualization of SCSI devices114,116to the client VM104and acts as the SCSI target.

In the figure, the first host computer102includes Storage Connectivity Group (SCG)111, which is associated with sets of Fibre Channel fabrics such as fabrics A162, B164, and C166and ports of those fabrics and a set of VIOSs, such as VIOS112and VIOS142, each of which controls storage traffic and storage connectivity for one or more virtual machines104a-104n,134a-134n. The SCG111is used to orchestrate traffic among the various VIOSs, fabrics, and ports of each fabric with which it is associated. Such orchestration can include isolating traffic for certain workloads to specific VIOSs, fabrics, and ports of each fabric and specifying redundancy of VIOSs, fabrics and host ports of each fabric in the manner that volumes are attached to virtual machines. Each SCG is assumed to be storage ready, which means that the VIOSs are running and one or more associated physical ports in each fabric are ready and able to support either NPIV connectivity or vSCSI connectivity.

The second host computer132has a similar configuration and includes hardware152, hypervisor/virtualization software155and client VMs134a-n. The hardware152includes one or more CPUs154, RAM156, a network interface158, and host storage160, such as one or more persistent storage devices. The RAM156contains programs in the form of instructions which are executed by the one or more CPUs154and which are stored on storage160and loaded into RAM156from storage160. Each client VM134a-nincludes a generic virtual SCSI disk136, a vSCSI interface coupled to a VIOS142via SCSI channel140. The VIOS142includes generic SCSI Logical Unit Numbers (LUNs)144,146, and one or more HBAs148,150. VIOS142is under the direction of SCG111running on host computer102. Alternatively, the SCG111can run on host computer132or an SCG can run on each host computer102,132and the SCGs can coordinate their activities.

The HBA118is coupled to switched fabric A162which is connected to one or more disks or storage arrays168, where a switched fabric is a network of nodes and switches which permit all nodes to communicate with one another via dedicated paths between nodes. Each node in the fabric has a unique address for communication, and a fabric can be described by the number of tiers it contains, where the number of tiers is the number of switches traversed between two nodes that are farthest from each other. The HBA120and HBA148are coupled to switched fabric B164which connected to one or more disks or storage arrays170. The HBA150is coupled to switched fabric C166, which is connected to one or more disks or storage arrays172. In one embodiment, the switched fabrics A, B, and C are Fibre Channel switched fabrics and HBAs118,120,148and150are Fibre Channel HBAs. Fibre Channel fabrics have ports that can be one of four different types, an N_Port, an E_Port, an F_Port, and a G_port. The N_Port is an endpoint in the fabric, also known as a node port, is the type of port to which the HBAs118,120,148,150are attached. The other types of ports, E_Port, F_Port, and G_Port, are ports internal to the fabric. In some embodiments, each N_Port in a switched fabric has a port ID, and the fabric supports virtualization of an N_Port ID. This virtualization, called NPIV, allows several virtual machines to share a common physical N_Port with each virtual machine using its own N_Port ID for that physical port node.

A switched fabric, such as a Fibre Channel Switched Fabric, permits the aggregating and sharing of all storage devices connected to the fabric. For example, fabric A162permits an HBA coupled to the fabric to aggregate and share all storage devices or arrays168. Fabric B164permits HBA120and HBA148to aggregate and share all storage devices or arrays170and fabric C166allows HBA150to share all storage devices or arrays172.

FIG. 2depicts a block diagram of a system that is representative of an alternative architecture in which embodiments may be implemented. The architecture includes host computers102and132with the same hardware122and152but with different virtualization software215,235and a different configuration of the client VMs202a-n,226a-n. In the first host computer102ofFIG. 2, the client VM202ais configured to have a specific type of disk204, such as an IBM2107, and a Virtual Fibre Channel (VFC) interface206to Fibre channel208according to a Fibre Channel Protocol (FCP). The Fibre Channel208is coupled to the VIOS210, which includes HBAs212and214. The HBAs212and214are Fibre Channel HBAs which are respectively coupled to fabric D240and fabric E242, which are Fibre Channel switched fabrics connected respectively to disks or storage arrays252,254. With the VIOS210operating as a pass-through device, disk204appears to the client VM202aas connected to fabric D240and fabric E242(represented by the dotted connections to the fabric) and the types of disks or storage arrays252,254attached to fabric D240and fabric E242match the type of disk204. The first host computer102includes SCG209which directs operations of the VIOS210. Alternatively, SCG209can run on host computer132or an SGC can run on each host computer102and132and the SGCs can coordinate their activities.

The second host computer132is configured similarly. Client VM226aincludes a specific type of disk228, such as an IBM2107, and a VFC interface230to Fibre Channel232. The VIOS234operates as a pass-through device and is respectively coupled via HBAs236and238to fabric E242and fabric F244, which are Fibre Channel switched fabrics. The VIOS234is also under the direction of SCG209and acts as a pass-through device from disk228to the fabrics E242and F244. Disk228appears to the client VM226aas connected to fabric E242and fabric F244(represented by the dotted connections to the fabric) and the types of disks or storage arrays254and256attached to fabric E242and fabric F244match the type of disk228.

FIG. 3depicts a flowchart of operations for deploying a virtual machine or attaching a volume to a virtual machine. In step302, the process, which in one embodiment is SCG111, initializes a Set of Fabrics to empty. In step304, the process sends an ‘interrogate’ request to the storage providers. In step306, the process determines whether or not a Set of Fabrics has been received from the storage providers. If so, then it uses the received set as the Set of Fabrics. If not, then in step308, it uses the fabric of the SCG111,209as the value of Set of Fabrics. Thus, the current fabric of the SCG111,209becomes the default Set of Fabrics. In step310, the process receives an operation, and in step312matches the operation to either a deploy virtual machine (VM) operation ‘Deploy_VM_op’ (A) or an attach volume operation, ‘Attach_Vol_op’ (B).

FIG. 4Adepicts a flowchart of operations for deploying a virtual machine. In step414, the process, which is the SCG111,209in an embodiment, obtains an intersection of fabrics based on the ports of the image volumes provided by the storage provider, where the intersection of fabrics includes those fabrics that are commonly connected to two or more host computers. For example, the intersection of fabrics for the architecture depicted inFIG. 1is fabric B164because it is common to both host computers102and132. In step416, the process determines a set of candidate host computers to which the VM can be deployed based on the intersection of fabrics. For example, continuing with the architecture ofFIG. 1, both host computers102132are candidates if fabric B164is the fabric needed by the VM being deployed. In step418, the process selects one of the candidate host computers102132, and in step420deploys the VM to the selected host computer.

FIGS. 4B and 4Cdepict a flowchart of operations for attaching a volume to a virtual machine. In step422, the process, which in one embodiment is the SCG111, determines a result based on the ports of the storage provider, the fabric of the storage provider and the VM to which the volume is to be attached. In step424, the process uses the result to determine whether the attachment is possible. Attachment is possible if one of the host computer systems and disk or storage array are connected to and logged into a common fabric. When hosts and storage are not logged in to a common fabric then no attachment is possible. If the attachment is possible, the process performs the attachment in step426. If the attachment is not possible and it is the NPIV attachment that is not possible as determined in step428, then a vSCSI attachment may be possible, and in step430, the process determines which host computers have the needed connectivity. For example, for the architecture depicted inFIG. 1, second host computer132may be the host computer with the needed connectivity because it is connected to fabric C166. In step432, the process determines whether the client VM104acan be migrated or not. If migration is permitted, then in step434the process migrates the client VM104ato the second host computer132which has the needed connectivity. In some embodiments, the migration in step434is performed according to the steps414-420ofFIG. 4A. In step436, the process performs the vSCSI volume attachment to the migrated client VM. For example, continuing with the example of the architecture inFIG. 1, a client VM104afrom first host computer102may be migrated to second host computer132because of the storage connected to Fabric C166. In step438, if the client VM cannot be migrated, then the process fails and sends a ‘greyOut’ of a field on a user interface display, where Send(‘message’ to destination) is an asynchronous non-blocking transmission of a ‘message’ to the ‘destination’ without being involved in the underlying communications mechanism.

Step440ofFIG. 4Cis executed if a volume is attachable as an NPIV attachment. In step440, the process determines whether the fabric available to the host computer is ‘OK,’ meaning acceptable for an NPIV attachment. For example, fabric E242inFIG. 2is a fabric that is acceptable for NPIV attachment. If so, then in step442, the process allocates a new Virtual Fibre Channel (VFC) for the VM. In step444, the process then performs an attachment of the volume. Allocating a new VFC includes allocating cables and connectors from those available to the process and mapping a channel to the cables and connectors with the channel conforming to the Fibre Channel protocol. Conforming to the Fibre Channel protocol includes implementing the Fibre Channel protocol stack, Fibre Channel Addressing, World Wide Names, Fibre Channel Frames, the structure and organization of the Fibre Channel data, Fibre Channel Flow Control, and Fibre Channel Service Classes. If the fabric available to the host computer is not acceptable for an NPIV attachment, then in step446, the process determines whether the VM can be migrated. If so, then in step448the process migrates the client VM to the host computer having an acceptable fabric. For example, fabric F244inFIG. 2may be a fabric that is acceptable for NPIV attachment so client VM202amay be migrated to second host computer132. In some embodiments, the migration in step448is performed according to steps414-420ofFIG. 4A. In step450, the process allocates a new VFC for the VM. In step452, the process then attaches the NPIV volume to the migrated client VM. If migration is not possible, then the process sends, in step454, the ‘greyOut’ message to a field on a user interface display to indicate a failure, i.e., that an attachment is not possible.

In some embodiments, attachments of volumes as other than vSCSI or NPIV attachment types is possible. Such other attachment types include Internet Small Computer System Interface (iSCSI), Non-volatile Memory Express over Ethernet (NVMe), and Non-volatile Memory Express over Fibre Channel (NVME-FC).

Thus, by querying the fabric of the storage provider to determine the connectivity it can support and by being able to migrate VMs to hosts having the needed connectivity, deploying VMs or attaching volumes to VMs is substantially more likely not to encounter an error.

Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g., an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In the context of the embodiments described herein, an application such as a long-running database application running in a VM may require additional storage space. The embodiments herein allow for a volume from any storage provider to be allocated and attached to the VM regardless of what fabrics the storage is on by determining a host that has connectivity to the storage and automatically migrating the VM to the host that is determined as having connectivity to the new volume and all the existing volumes that the VM requires. Doing so allows a user to use the VM with the additional storage from any computing system attached to a network connected to the cloud (e.g., the Internet).