Unified storage/VDI provisioning methodology

• US 10,248,448 B2
• Filed: 08/03/2016
• Issued: 04/02/2019
• Est. Priority Date: 06/11/2012
• Status: Active Grant

• Current Assignee: Omnissa, LLC
• Original Assignee: VMware, Inc. (Broadcom, Inc.)
• Inventors: Beveridge, Daniel James
• Primary Examiner(s): Bengzon, Greg C
• Application Number:
  US15/227,052
• Publication Number:
  US 20160342441A1
• Time in Patent Office: 972 Days
• Field of Search: None
• CPC Class Codes: G06F 2009/4557 Distribution of virtual machine instances; Migration and load balancing
• CPC Class Codes: G06F 2009/45583 Memory management, e.g. access or allocation
• CPC Class Codes: G06F 9/452 Remote windowing, e.g. X-Window System, desktop virtualisation protocols for virtual reality H04L67/131
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects

Abstract

Methods, computer-readable storage medium, and systems described herein facilitate provisioning a virtual desktop infrastructure having virtual shared storage. A provisioning manager receives a desktop pool type and provisions virtual shared storage among a cluster of hosts. The provisioning manager configures the virtual shared storage based on the desktop pool type and provisions at least one virtual machine to each host in the cluster of hosts. The provisioning manager optimizes the virtual shared storage by receiving a storage performance benchmark from each host and performing an optimization on the cluster of hosts if the storage performance benchmark results do not meet a threshold within a pre-defined tolerance.

Claims

1. A method for providing a virtual desktop infrastructure (VDI), the method comprising:

receiving an indication of a desktop pool type;

provisioning a plurality of virtual machines (VMs) to a host computing device, each of the plurality of VMs configured to execute a virtual desktop of the desktop pool type;

provisioning virtual shared storage for the plurality of VMs by using a storage manager on the host computing device, wherein provisioning the virtual shared storage includes tuning configuration settings of the virtual shared storage based on pool-related parameters associated with the desktop pool type;

detecting that a storage performance benchmark result indicating storage performance of the VMs utilizing the virtual shared storage does not meet a target threshold that is defined for the desktop pool type; and

executing an optimization loop to optimize the virtual shared storage by periodically modifying the configuration settings of the virtual shared storage and/or modifying an allocation of processor cores and/or random access memory (RAM) allocated to the storage manager.

2. The method of claim 1, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the virtual desktop is persistent, configuring the virtual shared storage to acknowledge write operations only after the write operations have been committed;

if the desktop pool type indicates that the virtual desktop is stateless, configuring the virtual shared storage to acknowledge write operations immediately without waiting for the write operations to be committed.

3. The method of claim 1, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the VMs are full clones, enabling deduplication on the virtual shared storage, otherwise if the desktop pool type indicates that the VMs are linked clones that share an underlying master image, disabling deduplication on the virtual shared storage.

4. The method of claim 1, wherein modifying the configuration settings further comprises:

modifying a redundancy level of the virtual shared storage if the desktop pool type indicates that the virtual desktop is persistent.

5. The method of claim 1, wherein executing the optimization loop further comprises:

re-tethering one or more of the VMs by migrating a VM from a first host computing device to a second host computing device in response to determining that the second host computing device hosts the storage manager that is being accessed by the VM.

6. The method of claim 5, wherein re-tethering is executed in response to determining that a dynamic resource scheduling process has caused the VM to be placed on a hypervisor that is different from a hypervisor hosting the storage manager.

7. The method of claim 1, wherein the storage performance benchmark result is a number of input/output operations per second (TOPS) or a measurement of latency associated with storage operations.

8. A computing device, comprising:

at least one processor; and

memory including instructions that, when executed by the at least one processor, cause the computing device to perform the steps of;

receiving an indication of a desktop pool type;

provisioning a plurality of virtual machines (VMs) to a host computing device, each of the plurality of VMs configured to execute a virtual desktop of the desktop pool type;

provisioning virtual shared storage for the plurality of VMs by using a storage manager on the host computing device, wherein provisioning the virtual shared storage includes tuning configuration settings of the virtual shared storage based on pool-related parameters associated with the desktop pool type;

detecting that a storage performance benchmark result indicating storage performance of the VMs utilizing the virtual shared storage does not meet a target threshold that is defined for the desktop pool type; and

executing an optimization loop to optimize the virtual shared storage by periodically modifying the configuration settings of the virtual shared storage and/or modifying an allocation of processor cores and/or random access memory (RAM) allocated to the storage manager.

9. The computing device of claim 8, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the virtual desktop is persistent, configuring the virtual shared storage to acknowledge write operations only after the write operations have been committed;

if the desktop pool type indicates that the virtual desktop is stateless, configuring the virtual shared storage to acknowledge write operations immediately without waiting for the write operations to be committed.

10. The computing device of claim 8, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the VMs are full clones, enabling deduplication on the virtual shared storage, otherwise if the desktop pool type indicates that the VMs are linked clones that share an underlying master image, disabling deduplication on the virtual shared storage.

11. The computing device of claim 8, wherein modifying the configuration settings further comprises:

modifying a redundancy level of the virtual shared storage if the desktop pool type indicates that the virtual desktop is persistent.

12. The computing device of claim 8, wherein executing the optimization loop further comprises:

re-tethering one or more of the VMs by migrating a VM from a first host computing device to a second host computing device in response to determining that the second host computing device hosts the storage manager that is being accessed by the VM.

13. The computing device of claim 12, wherein re-tethering is executed in response to determining that a dynamic resource scheduling process has caused the VM to be placed on a hypervisor that is different from a hypervisor hosting the storage manager.

14. The computing device of claim 8, wherein the storage performance benchmark result is a number of input/output operations per second (IOPS) or a measurement of latency associated with storage operations.

15. A non-transitory computer readable storage medium comprising one or more sequences of instructions, the instructions when executed by one or more processors causing the one or more processors to execute the operations of:

receiving an indication of a desktop pool type;

provisioning a plurality of virtual machines (VMs) to a host computing device, each of the plurality of VMs configured to execute a virtual desktop of the desktop pool type;

provisioning virtual shared storage for the plurality of VMs by using a storage manager on the host computing device, wherein provisioning the virtual shared storage includes tuning configuration settings of the virtual shared storage based on pool-related parameters associated with the desktop pool type;

detecting that a storage performance benchmark result indicating storage performance of the VMs utilizing the virtual shared storage does not meet a target threshold that is defined for the desktop pool type; and

executing an optimization loop to optimize the virtual shared storage by periodically modifying the configuration settings of the virtual shared storage and/or modifying an allocation of processor cores and/or random access memory (RAM) allocated to the storage manager.

16. The non-transitory computer readable storage medium of claim 15, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the virtual desktop is persistent, configuring the virtual shared storage to acknowledge write operations only after the write operations have been committed;

if the desktop pool type indicates that the virtual desktop is stateless, configuring the virtual shared storage to acknowledge write operations immediately without waiting for the write operations to be committed.

17. The non-transitory computer readable storage medium of claim 15, wherein tuning the configuration settings further comprises:

if the desktop pool type indicates that the VMs are full clones, enabling deduplication on the virtual shared storage, otherwise if the desktop pool type indicates that the VMs are linked clones that share an underlying master image, disabling deduplication on the virtual shared storage.

18. The non-transitory computer readable storage medium of claim 15, wherein modifying the configuration settings further comprises:

modifying a redundancy level of the virtual shared storage if the desktop pool type indicates that the virtual desktop is persistent.

19. The non-transitory computer readable storage medium of claim 15, wherein executing the optimization loop further comprises:

re-tethering one or more of the VMs by migrating a VM from a first host computing device to a second host computing device in response to determining that the second host computing device hosts the storage manager that is being accessed by the VM.

20. The non-transitory computer readable storage medium of claim 19, wherein re-tethering is executed in response to determining that a dynamic resource scheduling process has caused the VM to be placed on a hypervisor that is different from a hypervisor hosting the storage manager.