VDI desktops in a XenDesktop environment need to be able to register with a controller or multiple controllers so they can be managed by the broker and allow connections by clients.
In XenDesktop 4 the default was having the controller information held in an Active Directory OU. During installation you specified an AD OU and the controller installation added the AD objects to the OU so the Citrix Virtual Desktop Agent (VDA) that is installed within the guest OS could find the correct delivery controllers.
This has changed in XenDesktop 5 where the controller information isn’t by default added to AD and the client VDA is configured with the DNS names of the controllers (best to have at least two for redundancy) in the following registry key:
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
In this example my controllers are lonxd01.lab.int and nycxd01.lab.int
I think storing the controller information in AD which was the default in XenDesktop 4 was a great way of doing things as it gave you one less client VDA configuration setting to manage. If the controller information is stored in the registry and you need to add or remove a controller you have to reconfigure every client which can be a lot of work. If the controller information is stored in AD you can amend the setting in AD and all clients will be able to find the new controller without any VDA configuration change.
Read more…
Citrix has released a Beta of their next major XenServer version called “Project Boston”.
http://community.citrix.com/pages/viewpage.action?pageId=173115376
Some highlights from the new version release notes that I’ve spotted other than the expected performance enhancements are:
Read more…
Citrix XenServer 5.6 Feature Pack 1 is the latest release of XenServer but it is not supported as a hypervisor with either XenDesktop 4 or XenDesktop 5.
Have a look at the Citrix eDocs for Host Requirements / Hosting Infrastructure.
XenDesktop 4
http://support.citrix.com/proddocs/index.jsp?topic=/xendesktop-bdx/cds-hosting-infrastructure-reqs-bdx.html
XenDesktop 5
http://support.citrix.com/proddocs/index.jsp?topic=/xendesktop-rho/cds-sys-reqs-host-rho.html
XenServer 5.6 Feature Pack 1 has been out since 15 December 2010 and the release notes specifically mention enhancements to Provisioning Services and XenDesktop (only coming in a future release)
Provisioning Services improvements to Windows volume license (MAK and KMS) support.
XenDesktop platform enhancements. Provides local host caching of VM images to reduce storage TCO for XenDesktop VDI deployments. (Note: these platform enhancements will be enabled by a future version of XenDesktop).
XenDesktop 5 was released on 3 December 2010. OK, that’s only 12 days before XenServer FP1 but surely Citrix would have made the enhancements to XenDesktop 5 to support XenServer 5.6 FP 1…obviously not.
I’ve heard from Citrix that XenServer 5.6 Service Pack 2 is due for release soonish and will be supported by both XenDesktop 4 and 5. This does contradict somewhat with the release notes which state support will be in a newer version of XenDesktop rather than a newer version of XenServer.
If you are running XenDesktop 4 or 5 with XenServer 5.6 as the hypervisor, don’t upgrade to Feature Release 1, rather wait for Service Pack 2.
Going virtual is all about sharing resources. You are no longer constrained by one server or workstation running on one physical piece of hardware. The benefit is less physical kit to look after and better utilisation of resources but the detriment is when you share, you need to share nicely. In a shared environment one VM can be greedy and take more than its fair share and your other VMs suffer.
It’s not just sharing nicely that you need to consider but also building your VMs so they need less so there’s more to go around.
VDI is all about maximising the use of your physical hardware. To be cost effective (if you can with VDI!), you want to run as many workstations on a physical host as you can without sacrificing individual VM performance.
So, if your VMs are greedy with what they need you are going to be paying more for hardware. Wasting resources on physical workstations may not cost that much more but move your workstation into your datacenter and then see how much money you will be wasting.
Read more…
Citrix has just released some more information about its CPU masking technology for XenServer. Citrix calls it Heterogeneous resource pools which require a XenServer Enterprise or Platinum license. This technology is similar to VMware’s Enhanced VMotion Compatibility (EVC).
http://community.citrix.com/display/ocb/2010/10/26/CPU+masking+support+in+XenServer+5.6
These features use the capabilities built into the CPUs, either Intel’s FlexMigration or AMD’s Extended Migration to allow the configuration of a CPU to be changed by applying a CPU mask so it appears to provide different features than it actually does. This allows pools or clusters of hosts with different CPUs (from the same vendor) to support live migrations.
This is extremely useful as even CPUs with the same model number can have some differences which could cause XenMotion / Vmotion to fail. Newer generation servers with faster CPUs and even additional cores can be added into existing pools / clusters without any downtime.
Generally you need to start with hosts with the lowest capability CPUs and then add the newer revision ones which when added to the pool / cluster mask CPU features not available with the original CPUs. This can be done with all VMs online as the new hosts have the masks applied before any VMs start to run on the new host, maintaining compatibility with the existing pool /cluster.
If you are adding older hosts into a pool / cluster you would need to amend the mask of existing hosts which would mean all VMs would need to be shut down for this to work as a guest VM cannot downgrade its CPU capabilities while running.
Citrix has also helpfully released a Heterogeneous CPU Pool Self-Test Kit so you can check your CPU compatibility.
http://www.citrix.com/ready/hcl
Recent Comments