cpekar
Contributor
Contributor

Error During Provisioning - Linked Clones

Jump to solution

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!

0 Kudos
1 Solution

Accepted Solutions
Kitu045
Enthusiast
Enthusiast

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

Pradeep K Yadav Pradeep045@gmail.com VMware & VDI administrator

View solution in original post

0 Kudos
17 Replies
admin
Immortal
Immortal

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.

0 Kudos
cpekar
Contributor
Contributor

Actually, you have it backwards.

I can create 20 desktops (200 gigs), but unable to create 5 linked clones.

0 Kudos
cpekar
Contributor
Contributor

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.

0 Kudos
cpekar
Contributor
Contributor

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.

0 Kudos
admin
Immortal
Immortal

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?

0 Kudos
cpekar
Contributor
Contributor

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.

0 Kudos
cpekar
Contributor
Contributor

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:

  • /BCDatacenter/host/BC
    Cluster/FC Datastore 1
    Used for: User data \


Storage overcommit: Conservative

  • /BCDatacenter/host/BC
    Cluster/FC Datastore 3
    Used for: OS Data \


Storage overcommit: Conservative

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.

0 Kudos
admin
Immortal
Immortal

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!

0 Kudos
Kitu045
Enthusiast
Enthusiast

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

Pradeep K Yadav Pradeep045@gmail.com VMware & VDI administrator

View solution in original post

0 Kudos
kovals
Contributor
Contributor

I also set the "Stop provisioning on error" option to False and since then my life is easier... :smileygrin:

cpekar
Contributor
Contributor

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!

0 Kudos
cpekar
Contributor
Contributor

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!

0 Kudos
pmcwhor
Contributor
Contributor

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...

0 Kudos
mikebarnett
VMware Employee
VMware Employee

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

Twitter: @MikeBarnett_
0 Kudos
pmcwhor
Contributor
Contributor

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.

0 Kudos
mikebarnett
VMware Employee
VMware Employee

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

Twitter: @MikeBarnett_
0 Kudos
ehaniffa
Contributor
Contributor

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

0 Kudos