Wow, a lot of jumping between XenServer, Hyper-V and vSphere this week. It really was fun, fun, fun until I had to take my daugher’s T-bird away. But that is yet another story.
Today’s topic is everyone’s favorite xml file, proxy.xml. What fun! Ah, the pleasant days spent in a customer’s datacenter, conference room, or cube hacking away at this file. I could tell you stories only fit for the “National Enquirer”. Unfortunately today I am only going to tell stories about why this particular CTX article is so important.
CTX125578 XenDesktop Error: The hosting infrastructure could not be reached at the specified address
So here is the problem. You are just cruising along, minding your own business, trying to install XenDesktop. You have a nice frosty Big Gulp, then a few Next Next Next’s and suddenly you can’t reach hosting infrastructure. Now this may be true of your datacenter is in another building, campus or another room, but what if it is in a rack arms length from your laptop? I, for example can walk across my office to where the AC air intake is and I can definitely “reach my hosting infrastructure”. In fact if I stand in the right place I can reach 4 different hosting infrastructures. I look like a Jabba the Hut playing Twister, but I can reach them.
I guess the message is implying “reach the hosting infrastructure” from the NETWORK. Oh. That makes more sense.
So lets look at the first step. Hosting infrastructure isn’t really talking about all of the specific hypervisor hosts when its XenDesktop involved. In fact, XenDesktop is not really all that interested in all of the hosts in your virtualization infrastructure. XenDesktop is more interested in how your machines are controlled inside of your virtualization infrastructure. So, while in a XenServer environment all of the hypervisor hosts have some ability to contact the idea how things are run, what and which host is in control, things don’t run that way in Hyper-V and vSphere. In fact, while you can run the xe command: xe role-list
You can find out the roles in a XenDesktop pool.
vm-power-admin: The VM Power Administrator role has full access to VM and template management and can choose where to start VMs and use the dynamic memory control and VM snapshot features
vm-admin: The VM Administrator role can manage VMs and templates
vm-operator: The VM Operator role can use VMs and interact with VM consoles
read-only: The Read-Only role can log in with basic read-only access
pool-operator: The Pool Operator role manages host- and pool-wide resources, including setting up storage, creating resource pools and managing patches, high availability (HA) and workload balancing (WLB)
pool-admin: The Pool Administrator role has full access to all features and settings, including accessing Dom0 and managing subjects, roles and external authentication
When you have a Hyper-V virtualization infrastructure you will need to connect to your SCVMM (System Center Virtual Machine Manager) server. For vSphere you will connect to your vCenter server. This is what controls the machine state of the virtual machines. How they will power on and off etc. The mechanisms for power on and off are important because of Provisioning Services. Getting the virtual disk out to machines and overall initiating the boot process for PXE or TFTP to get the machine up and running. The other benefit is to make sure you can conserve hypervisor resources when virtual desktops are not needed. This opens up the ability to step processor power, shut down cores, sockets and servers to conserve energy.
Back to the proxy.xml, this file is responsible for configuring how the vCenter server will respond to SDK requests. By default it is configured to HTTPS only. Hey who doesn’t like secure? The problem is that when you are connecting to an ssh server via a terminal connection you can just accept the ID of the server and log in and hack away. When you are connecting to the vCenter SDK, by default you have to make a secure connection. And a secure connection means you have to be able to identify the target by hostname resolution, not just ipaddress. You don’t want me to drop a copy of my vCenter vm called vCenter.phxdemo.tokeshi.com in the middle of your environment and collect all of your vCenter passwords do you? Especially just because we both happen to call our vCenter servers “vcenter”, now your vCenter.contoso.com is getting it’s traffic intercepted by my vCenter server. Bad, bad, bad.
The funny part is that it is a bit of a hassle to get a certificate, it used to cost hundreds of dollars to get a publicly verified certificate, now it still costs hundreds of pennies to get a certificate. (As much as a 15 minute phone call according to some commercials.) So some people leave the default certificate on the vCenter server and this certificate is referenced as the host “vmware”. So all you have to do is put a reference in your XenDesktop infrastructure for “vmware” and the vCenter ipaddress, or better yet you can add vmware to your DNS, and now all you have to do is trust the private cert on the vCenter server. If you think this is a secure idea, I can “secure” your credit card information for you if you mail me your credit cards, ID, social security card, and your birth certificate. (No, please don’t I’m kidding. Really. Put down the envelope. Just PayPal me a few bucks and we’ll call it even.)
It’s not all that bad to do the vmware host name/ built in certificate workaround in a lab or something just do us all a favor and let’s not do it in production. Not even in POC. (Mainly because POC ends up standing for Production On Completion, not Proof Of Concept).
Hopefully this has given you a little insight as to why all of this hoopla about the proxy.xml.
Thanks for hanging out here for a while,
from Rat’s Citrix Blog