Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: Described herein are techniques to decompose a measurement of the latency experienced by a virtual machine into its additive components (e.g., host latency, kernel latency, network latency and storage latency). The host latency may be determined as the aggregate latency reported from the virtual disk of the virtual machine minus the aggregate latency reported from the datastore on which the virtual disk is stored. The network latency may be determined as the device latency reported from the datastore minus the storage latency reported by a storage system. Various sensor measurements (e.g., aggregate latency reported from the virtual disk and/or datastore) may be first pre-processed to compensate for non-idealities before being combined with other sensor measurements.

Abstract: Described herein are techniques for configuring a volume shadow copy service (VSS) requester and/or VSS provider so that a snapshot may be taken of application data stored on a virtual volume (VVOL). The VSS requester may receive a request to take a snapshot of a VVOL, the VVOL identified by a VVOL identifier. The VSS provider associated with a storage array may determine whether the storage array supports taking the snapshot of the VVOL. The determination may be based on information derived from a mapping which maps respective VVOL identifiers to respective logical unit identifiers. If the VSS provider supports taking the snapshot of the VVOL, the VSS provider may take the snapshot of the VVOL.

Abstract: Described herein are techniques to decompose a measurement of the latency experienced by a virtual machine into its additive components (e.g., host latency, kernel latency, network latency and storage latency). The host latency may be determined as the aggregate latency reported from the virtual disk of the virtual machine minus the aggregate latency reported from the datastore on which the virtual disk is stored. The network latency may be determined as the device latency reported from the datastore minus the storage latency reported by a storage system. Various sensor measurements (e.g., aggregate latency reported from the virtual disk and/or datastore) may be first pre-processed to compensate for non-idealities before being combined with other sensor measurements.

Abstract: Techniques are described herein which minimize the impact of virtual machine snapshots on the performance of virtual machines and hypervisors. In the context of a volume snapshot which may involve (i) taking virtual machine snapshots of all virtual machines associated with the volume, (ii) taking the volume snapshot, and (iii) removing all the virtual machine snapshots, multiple virtual machine snapshots may be created in parallel. In the process of creating virtual machine snapshots, a storage system may determine which snapshots to create in parallel. The storage system may also prioritize snapshots from certain hypervisors in order to avoid the problem of “starvation”, in which busy hypervisors prevent less busy hypervisors from creating snapshots. The techniques described herein, while mainly described in the context of snapshot creation, are readily applied to snapshot removal.

Abstract: Storage administrators would like to create snapshots of a storage array as frequently as possible, but too many concurrent snapshots can place an unnecessary load on the storage array. Described herein are techniques for scheduling snapshots on the storage array with the objective of minimizing the maximum number of simultaneous snapshots and/or temporally spacing apart snapshots from each other.

Abstract: Described herein are techniques for configuring a volume shadow copy service (VSS) requester and/or VSS provider so that a snapshot may be taken of application data stored on a virtual volume (VVOL). The VSS requester may receive a request to take a snapshot of a VVOL, the VVOL identified by a VVOL identifier. The VSS provider associated with a storage array may determine whether the storage array supports taking the snapshot of the VVOL. The determination may be based on information derived from a mapping which maps respective VVOL identifiers to respective logical unit identifiers. If the VSS provider supports taking the snapshot of the VVOL, the VSS provider may take the snapshot of the VVOL.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: Storage administrators would like to create snapshots of a storage array as frequently as possible, but too many concurrent snapshots can place an unnecessary load on the storage array. Described herein are techniques for scheduling snapshots on the storage array with the objective of minimizing the maximum number of simultaneous snapshots and/or temporally spacing apart snapshots from each other.

Abstract: Techniques are described herein which minimize the impact of virtual machine snapshots on the performance of virtual machines and hypervisors. In the context of a volume snapshot which may involve (i) taking virtual machine snapshots of all virtual machines associated with the volume, (ii) taking the volume snapshot, and (iii) removing all the virtual machine snapshots, multiple virtual machine snapshots may be created in parallel. In the process of creating virtual machine snapshots, a storage system may determine which snapshots to create in parallel. The storage system may also prioritize snapshots from certain hypervisors in order to avoid the problem of “starvation”, in which busy hypervisors prevent less busy hypervisors from creating snapshots. The techniques described herein, while mainly described in the context of snapshot creation, are readily applied to snapshot removal.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed for redeploying a baseline VM (BVM) to one or more child VMs (CVMs) by merely cloning virtual drives of the BVM, instead of the entirety of the parent BVM. A temporary directory is created in a datastore that has the target CVMs that are targeted for virtual drive replacement (e.g., are to be “re-baselined”). One or more replacement virtual drives (RVDs) are created in the temporary directory, where the RVDs comprise a clone of a virtual drive of the source BVM. The one or more RVDs are moved from the temporary directory to a directory of the target CVMs, replacing existing virtual drives of the target CVMs so that the target CVMs are thus re-baselined to the state of the parent BVM.

Abstract: One or more techniques and/or systems are disclosed that provide for cloning VMs, where different parts of the same VM are cloned separately. A temporary repository directory in a datastore of a storage controller is populated with a copy of one or more source virtual drive image files, which were generated from a source virtual machine (SVM) that is being cloned. A diskless virtual machine (DVM) is created in a destination container using configurations from the SVM. The copy of the one or more source virtual drive image files is cloned a desired number of times corresponding to a desired number of virtual machine clones. The DVM is cloned a desired number of times corresponding to a desired number of virtual machine clones. The DVM clones are combined with the source virtual drive image file clones in the destination container.