JackMac4's Accepted Solutions

Yes, that is correct. the SS's are paried to a CS, but once you've connected to the broker, it can channel the SITE B's desktop over the back channel and present it to the site A external client.

You don't need to split the luns per replica. I would put all your replicas on SSD, and yes they can share a LUN across many pools. You'll just want to have multiple LUNs that the pool(s) can balance over. Create as many LUNs as you need to spread things out, but really think about spindles and IOPs. 128 is a guideline, but not a hard rule. It's all about having enough IOPs to serve the requests you'll get during peak use. I would go with SAS if you can, but SATA is acceptable - it just all affects user experience. Consider using SATA for task workers or people that don't generate a lot of storage use. Trial and error and user acceptance would be good to go through here if you haven't yet.

It depends on if you have tunneling configured. Check your SS and CS settings for tunneling. If you tunnel everything then you should see the traffic go client <-> ss <-> cs <-> agent otherwise it could go client <-> ss <-> agent

8KB is recommended for some storage. Most people don't bother aligning these days, since there is a lot of auto alignment out there, but if EMC recommends it there should be no problem with an 8K block size. I believe NetApp recommends this for some arrays as well, so I don't think EMC is alone. There should be plenty of articles out there on partition alignment with vmware and view, I would dig around through those.

I'm a tad unclear - which order did you install? If you've installed the VMware Tools after the View Agent, you'll need to uninstall and reinstall the View Agent.. It ALWAYS must be installed last, even if you are just updating tools. Also, Windows 8.1 is not supported with View 5.1 IIRC

Zaim33, The purpose of disabling a pool is to stop everything, but not delete it. You can disable a pool to stop logins and provisioning, queue the operations you want, and re-enable the pool. Because we allow inline maintenance it has never been a real issue. You can always recompose individual desktops or even groups, rather than the entire pool if you need to do maintenance while a pool is in use. Once you've marked VM's for a recompose, of course they will become unavailable for login. There are a number of strategies for doing this to keep things moving while the pool is in use. This has been by design ever since View 4.5ish. If you need some help figuring out the best way to plan maintenance, let me know!