Netapp, Inc.

Hewlett Packard Enterprise Development LP

Eric P Forgette

George Costea

Shravan Gaonkar

Deepak Raghu Kenchammana-Hosekote

Arthur F Lent

Matthew Douglas Robinson

Peter R Learmonth

Michael Vaughn Stewart

Subramaniam Periyagaram

Andrew G Tucker

Jose Mathew

Mohit Gupta

Varun Jobanputra

Sisir Shekhar

Anagha Barve

Daniel A Sarisky

Juhsun Wang

Vishwajith Shivappa

Raymond Mark Cooke

Gaurav Ranganathan

Razvan George Costea

Manu Mehrotra

Jonathan K Rippy

Jonathan H Dascenzo

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.

Redeploying a baseline virtual machine to update a child virtual machine by creating and swapping a virtual disk comprising a clone of the baseline virtual machine

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.

Methods and systems for pre-processing sensor measurements

One or more techniques and/or systems are provided for hosting a virtual machine from a snapshot. In particular, a snapshot of a virtual machine hosted on a primary computing device may be created. The virtual machine may be hosted on a secondary computing device using the snapshot, for example, when a failure of the virtual machine on the primary computing device occurs. If a virtual machine type (format) of the snapshot is not supported by the secondary computing device, then the virtual machine within the snapshot may be converted to a virtual machine type supported by the secondary computing device. In this way, the virtual machine may be operable and/or accessible on the secondary computing device despite the failure. Hosting the virtual machine on the secondary computing device provides, among other things, fault tolerance for the virtual machine and/or applications comprised therein.

Virtual machine fault tolerance

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.

Methods and systems for integrating a volume shadow copy service (VSS) requester and/or a VSS provider with virtual volumes (VVOLS)

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.

Methods and systems for concurrently taking snapshots of a plurality of virtual machines

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.

Methods and systems for optimal snapshot distribution within a protection schedule

One or more techniques and/or systems are provided for describing virtual machine dependencies. In particular, data objects, such as virtual hard drives, associated with virtual machines may be identified and/or examined to identify data structures, such as configuration files, comprising configuration data. The configuration data may be analyzed to determine dependency relationships between virtual machines to describe virtual machine dependencies. Identifying virtual machine dependencies, among other things, allows virtual machines that are no longer used to be repurposed, deleted, reset, etc. with little to no adverse effect on other virtual machines.

Virtual machine dependency

Systems and methods that enable the optimal creation of a storage object within a virtual storage system are disclosed. In accordance with embodiments, an optimal location with the storage system is determined in response to receiving an indication that a storage object is to be created within the storage system. The system and method prioritize physical storage resources in which to create the storage object, prioritize components to be provided access to the created storage object, and prioritize the interface between the physical storage resources and the accessing component. The storage object is optimally created within the storage system based on the priorities and based, at least in part, on other created storage objects.

System and method for optimally creating storage objects in a storage system

While current solutions for cloning virtual machines can involve copying and duplicating files associated to a virtual machine (VM), systems and techniques can be devised to create thin clones of a VM using the VM's associated storage system to copy and deduplicate storage for the VMs. One can create a base VM in a directory of a storage container attached to a hypervisor, and then map the storage container to a volume on a storage system. One can clone the base VM using a snapshot of respective files associated to the base VM, which can comprise creating metadata that identified a physical storage location of the files. Further, the metadata can then be copied to a desired location on the storage container, to create a VM clone. Once copied, the cloned VM can be customized and registered within the hypervisor.

Cloning virtual machines

Redeploying baseline virtual machine to update a child virtual machine by creating and swapping a virtual disk comprising a clone of the baseline virtual machine

Growing community of inventors

Sunnyvale, CA, United States of America

Eric P Forgette