williambishop's Accepted Solutions

It cleans up after it returns online, and is available capacity for the next fail, create, etc. It is not a failback scenario...unless someone much more experienced comes along to correct me, I will go with Duncan's statements so far on the matter.

By no means are you restricted to a 1:1 ratio. I've had servers people told me had to have maximum throughput, and I put them in with 2 or 3 others, only to find their definition of fast and mine were different, and later moved them into volumes with a dozen vm's(my definition of fast is over 400MB a sec constant). Your performance isn't really determined by this, but rather by the array. That said, I never use a 1:1 ratio....it's unnecessary, and I've hundreds of servers and thousands of vdi desktops in vmware...including some that were migrated from big ibm iron (what we generally call a "heavy" server).

Mike laid that one out. I'm assuming it's for virtual center, which some data loss is not usually an issue....If it's for something else, I'd think long and hard about not going simple. Most databases need as much recovery as you can get them, where the majority of their data is not performance data or something superfluous.

There are restrictions on installing it on another server(iirc), most people commonly install it on the vc server. I don't know of any performance penalty for doing so, I manage 2 datacenters and 2500 guests(nearly 100 hosts) on the one box with no issues.

While vmsight is amazing, and I'm sure vizioncore is as well, I think we need something simple for such a simple task. When I get some time I'll see if I can't figure out how to extract this bit of info from the database itself. Last login time can't be that hard.

You don't have to add a sound adapter to the vm's as far as I remember. RDP provides a virtual sound driver. RDP into your session and play a sound. Make sure your device is set to bring sound to local device.

A step further. A good reason for esx, would be that you will be prepared for the time when you DO expand. ESX is a light year better than server, in performance and value. I'm not saying server isn't good, because it is. But I never breathed so easy as the day we moved our last vm from server to esx. You can also think about nfs, which provides much of what you are looking for in a san, and gives you the HA options as well. Netapp runs on this, and it provides thin provisioning. I've gotten good performance from nfs shares running on a linux box with a decent raid array.

Yes, XP 296MB, 5gig image. You'll have to judge for yourself based on the workloads. For mostly office users, the number is astronomical before you run into i/o errors...Ours, clinical apps, is a lot lower. But we are a hospital, so while we may have a thousand active vm's, they are not all truly active at the same time. Most environments are roughly the same, where you see about 60% utilization at any given time, so it allows you to increase the density. For servers, the numbers are much lower, because it's actual i/o(vs, swap file, web access, etc for VDI) movement. I've got entire luns that may not see 15 meg a second transfer for 200 users. Then again, I have server luns with 5 users on it that are moving near capacity. Factors are going to be: Back end storage(including all it's factors, type, disks, cache amount, pathways(number of fabrics, etc)....and so forth Front end(how many hba's are you connecting from your server, for how many volumes) VMguest purpose(desktop/server) VMguest IO needs(server----does it do a database? if so, your needs are going to be higher). That's why there's no really good writeups, there are far too many factors and options out there. Additionally, I'm using the new "experimental" hba round robin on one of my blades and luns, and so far I LOVE it.... \ W.

We've looked at the technology, but not played with it yet. Interested in your review. That said, logically, it would seem like a fit for "fixed" since all of the actual work is done "behind" the svc. Of course, I'm can be(and probably am) wrong.