VMware Horizon Community
Chris_S_UK
Expert
Expert

VMware View Composer Design Considerations document

There is some odd advice in this document, it seems to me.

On page 3, it states:

"VMware recommends that you run a maximum of 64 virtual machines per replica. Having more virtual machines may cause storage bottlenecks in the storage I/O subsystem. You should allocate enough space on the datastore to accommodate 64 virtual machines. You need to account for virtual machine growth when choosing the size for this datastore. A virtual machine can grow for various reasons, including growth of the page file and temporary files. You may need to do some modeling during the pilot phase to understand system growth in your environment."

OK, so this is advising to limit the number of VDI desktops on each datastore to 64 or thereabouts. Fair enough, the VMware View Reference Architecture also says something similar.

However, on the same page it says:

"VMware recommends that you keep all the desktops in a particular desktop pool (for example, the finance pool) contained within the same datastore (LUN). Splitting desktops from a particular pool across LUNs reduces the total storage saving you can gain by using View Composer because View Composer must create multiple replicas, one for each datastore."

So this seems to be saying that you shouldn't have a pool containing more than 64 machines because, if you do, you should spread it over multiple datastores and this itself is not recommended. However, if you need more than 64 machines and you create separate pools, with 64 in each, then you're going to have the same wasted space (owing to extra replicas) anyway!

Given that a typical replica for XP will be only 6-10GB anyway, I don't see a big issue with having larger pools spread over multiple datastores with approx 60 desktops in each.

Anyone have any comments?

Chris

Reply
0 Kudos
5 Replies
asrinivas
Contributor
Contributor

Hi Chris,

You can have a pool span multiple datastore. That is not a issue. View does a good job balancing your desktop. The idea of not mising different types of pools(desktop types) on the same datastore is to maximize your storage savings.

Imagine you have a datastore with only one type of desktops(pool)..say XP. then there is only one replica image..if the image size was say 10GB then the replica space consumed is also 10GB..and the linked clones can stayu on the datatstore. In case you mix and also use the same datastore for say a vista pool, then replica for vista also resides on that datastore making your strage savings a litle smaller.

So , in summary the idea is not to limit the pool to the same datastore..it can span many depending on how many desktops you need, the idea is to not have many pool types on the same datastore.

Thanks

Anjan

Reply
0 Kudos
Chris_S_UK
Expert
Expert

Thanks for the reply.

My point exactly - you say "the idea is not to limit the pool to the same datastore" but they say not to spread pools across datastores.....their 2 points and contradictory!

Reply
0 Kudos
asrinivas
Contributor
Contributor

No. I dont think you understood..

I suggest reading the View Composer informaiton guide to understand the repliaca operation when a pool is created.

Here is a example:

if you need to have 120 XP desktops - use two LUN's with 60 desktops each..( so you can span it and not worry about it ). This is not a problem. I am not saying not to View automatically does this for you.

What i am saying is : one a LUN tha has XP desktops...as a "best practice" dont deploy multiple image types..i.e. dont have multiple desktop types installed on the same datastore. So dont use the same datasore to deploy XP,Vista,XPSP1 etc..

Does this help calrify? if not pass me a way to talk to you and i shall call to carify.

TomHowarth
Leadership
Leadership

Chris, what they are talking about here on the face of it does appear contradictory I agree, however they are talking about two differnent concepts, the first pertains to traditional full clone desktops and is a standard VMware tenant. the second pertains to linked clones and here you can have greater numbers of machines per LUN,

Futher the 64 machine limit is just a recommendation not a fact.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

Contributing author for the upcoming book "VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment”.

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
jaffa-unisys
Enthusiast
Enthusiast

Kia Ora.

I have a similar concern in reading this section of the Design document . Say you are unable to split your LUNs to approximately the size of (for arguments sack 64) 64 guests; master image, personality disks, growth, overhead. You have a very large LUN so space is not a concern. And its not to bad on speed and all that. (or you have no choice); are you still concerned with I/O bottle neck 'within the Virtual infrastructure' or is this strictly speaking only at Hardware level?.

ie. is the i/o bottle neck a problem if you had 200 desktops off of one image replica?

or, do you need to split the users into Pools of approximately 64 desktops thus providing you with, in my case of 200 desktops, 4 pools = 4x replicas? (though on1 LUN)

cheers all

Reply
0 Kudos