Currently running ESX 3.5 update 4, View version 3.1.2.
I'm having the following issue, when I try to setup linked clones, when just creating 5 desktops.
Error during provisioning9/21/09 2:36:19 PM EDT: Insufficient disk space to provision new desktops. Existing free space is reserved for the growth of virtual machines already placed on the datastore. Please allocate more space for new virtual machines or change the storage overcommit option selected for the datastore
Can someone point me in the right direction to fix this issue? I can create 20 non-linked clones just fine, so space should not be an issue.
Thanks!
stop provisining on error - False
Do this settings and check...I had the same issue...there is issue of calculation of free space...
required free space is not available means after creating the Vms its need more free space...
Just check......and confirm back..
Pradeep K Yadav
Pradeep045@gmail.com
VMware & VDI administrator
I am a Product Manager in View Desktop team.
The View Admin uses a formula to ensure that enough spare spaces are available at the time of
Pool creation to fit the # of Desktop VMs in question. You can use the different modes: "Aggressive" vs
"Conservative" to direct the calculation. However, regardless of the mode, the available spaces required
for a successful pool creation would have been greater than just creating link-clones. This might
explain the fact that you couldn't create the Desktop VMs while creation of larger number of
linked-clone was successful.
Actually, you have it backwards.
I can create 20 desktops (200 gigs), but unable to create 5 linked clones.
The most I can create is 3 clones. Which to me, means that that the space issue isn't pointed at my datastores, but somewhere else.
More information, I can create 3 non-persistant clones, but can't create any persistant clones. Also, from the 3 created clones, I can expand back up to 10 clones (non-persistant).
I'd love to know what is causing my issue. The manual isn't really helping, unless, I'm just not looking in the right place.
Thanks for the additional info. I'd like to know the Pool settings of your non-persistent pool. What's
the minimum/maximum/head-room values? Do you set storage planning mode to aggressive or
conservative?
If you are talking about the min/max/head-room of the advanced option, well I don't change that. I keep defaults.
Also, I've tried, agressive, conservative and none.
Type: | Automated Desktop Pool | ||
Desktop persistence: | Persistent | ||
Unique ID: | ossi | ||
Display name: | ossi training | ||
State: | Enabled | ||
Provisioning: | Enabled | ||
Number of desktops: | 10 | ||
Stop provisioning on error: | True | ||
When VM is not in use: | Do nothing | ||
VM naming pattern: | Training | ||
Automatic logoff after disconnect: | Never | ||
Refresh OS disk on logoff: | Never | ||
Allow users to reset their desktop: | False | ||
Default display protocol: | Microsoft RDP | ||
Allow users to override the default protocol: | False | ||
Adobe Flash quality: | Low | ||
Adobe Flash throttling: | Moderate | ||
VirtualCenter server: | 192.168.17.100 | ||
Use View Composer: | True | ||
Parent VM: | /BCDatacenter/vm/Discovered Virtual Machine/xp gold - base | ||
Image: | /link | ||
User data disk: | 😧 | ||
User data disk size: | 2048 MB | ||
Virtual machine folder location: | /BCDatacenter/vm/Discovered Virtual Machine | ||
Host or Cluster: | /BCDatacenter/host/BC Cluster | ||
Resource pool: | /BCDatacenter/host/BC Cluster/Resources | ||
Datastore: |
|
|
|
Total free space: | 252.5 GB | ||
Total capacity: | 1,069 GB | ||
Domain and account for QuickPrep: | bartholomewco.com (administrator) | ||
Description: | Full install of OSSI Suite of Applications. |
Thanks for the detailed info.
After looking over this case with an in house expert, we think the best way to resolve this is to try
to generate a log bundle and open an SR to report this.
That said, we wonder if you could try a few things to help narrow down the issue and help us resolve it.
First, we observed 2 Datastores. If possible, we suggest you try to use only one Datastore to see if
you problem would go away with only one datastore with sufficient disk spaces for 10 (or x) desktops.
Second, we would like to try create 2 pools, each having 5 desktops max and each running on just
a single datastore to see if that works.
We definitely should support multiple datastores, just want to check if some problem in free space
calculation and/or our control algorithm in creating clones in data stores.
Thanks!
stop provisining on error - False
Do this settings and check...I had the same issue...there is issue of calculation of free space...
required free space is not available means after creating the Vms its need more free space...
Just check......and confirm back..
Pradeep K Yadav
Pradeep045@gmail.com
VMware & VDI administrator
I also set the "Stop provisioning on error" option to False and since then my life is easier... :smileygrin:
Actually, I've tried all those suggestions in the past, so, that really hasn't helped. But, thanks for the thought.
On the unchecking the box for stop on failure, I will be trying that next.
Thanks!
Well, I'll roll the die for who gets the points and final answer.
Basically, unchecking the box fixed the issue, sorta, but also changing the data disk size from 2GB to 512MB also worked out.
Soon, we'll be having another datastore on our san dedicated to desktops.
Thanks, for the help!
I encountered this problem recently. I was creating the vm's across 3 datastores. When the failure occurred, I had 300 gb free on each datastore. VM base disk was 20 gb - No user data partition. Rather than fighting the problem, I simply changed my storage overcommit option from 'None' to 'Conservative.' I'm not fond of thin provisioning. The remainder of my vm's were immediately created on the same 3 datastores. Doesn't make much sense to me...
Thin-provisioning is the very essence of using the linked clone technology with View. If you don't like thin-provisioning then you can always just use regular clones instead of linked clones.
Conservative is unlikely to get you into too much trouble unless your users are installing lots of software on the VMs or you are defragmenting them at all.
Mike
I agree with your answer. However, this doesn't explain the erroneous message from View stating that my datastores were out of space. This seems to be the core of cpekar original question that hasn't yet been answered.
Ah, ok. I missed that.
So when View deploys VMs it calculates the number of VMs being deployed and the amount of space available. If you have a 20GB image and a 300GB datastore and you set the storage overcommit to None you will only be able to deploy 15 VMs per datastore before it runs out of space. When you set it to Conservative or above it will allow you to deploy more VMs than the datastore could hold if each of the linked clone disks was to grow to the maximum size.
This is where you need to plan ahead for how large you expect the linked clones to grow. If you will be recomposing or refreshing or you are using a non-persistent pool with the Delete after first use option then your VM disks aren't likely to grow very much at all and in this case you can use a higher overcommit setting. If you are planning on having a large number of persistent desktops and not recomposing very often then the highest overcommit you will likely want to use is Conservative.
Let me know if you have any more questions.
Mike
Hello all,
This came up when I was doing a search on recommendations on Thin provisioning and Linked clones. We're about to rebuild a few master images and some pools and I was wondering what the recommendations were around using thinprovisioned master image HD's or if that is even supported in view