Importantly there are two kinds of pools in Horizon: automatic and manual. Automatic pools are pointed to a specific template and spawn new machines based on that template, and manual pools will accept the importation of, really, any viable virtual machine.
But what if you find that you need to move a machine from one location into an automatic pool. There is no intended functionality for doing this. However, we are humans and we are clever.
I will lay out for you the procedures I used. We have a domain and our machines are all domain joined. You may want to make adjustments for your specific situation, but the essentials here should guide you nicely.
Before you begin, let your user know that there machine will be unavailable for half an hour to an hour and that you will want them to test access once you have made the changes.
- Remove the entitlement for that user from the machine and the pool.
- Remove the machine from the domain and shut it down.
- Delete the machine object from Active Directory.
- Use the Clone to Template function in vSphere to clone the machine to a safe template location.
- (You may at this point delete the original VM.)
- In Horizon, point the destination pool at your newly cloned template.
- Add a new machine to the automatic pool from the template you just cloned.
- Point the destination pool back to its preferred template.
- (You may at this point delete the cloned intermediary template.)
- Power on the newly added virtual machine and add back to the domain.
- (Move it to the correct OU in AD.)
- Entitle the user for the destination pool and newly cloned machine.
It’s a bit of a hassle but it has worked dozens of times for me.
I have been having this problem on a VM pool replica master. Don’t worry about what that means if you are not familiar with machine pools (VMware); it’s not important. The important part is that I was not able to save certain files I was downloading with Firefox to the Desktop.
The download process would proceed as expected up until the end of the download. Then when Firefox would merge the two files of the download into the single file which was the actual downloaded file, it would fail. Every time.
I tried running Firefox in its safe mode (no extensions). Nada.
I tried using Revo Uninstaller to utterly remove all traces of Firefox (as IE, Chrome, and Opera did not have this issue) from the machine. After rebooting and re-installing Firefox the problem persisted.
Eventually I found an obscure mention of a service called Application Experience. If that service is disabled, this sort of thing can happen. I checked my personal VM and found that this service was set to Manual.
So I changed that replica master to Manual and rebooted it.
No problem saving the 64 bit Java installer downloaded through Firefox to the Desktop.
It’s an odd connection. Hope this helps you too.
I have been upgrading certain machines here at work and testing various items along the way. First one item of concern.
There is a great package out there for Windows domain integration called likewise-open. We had a 13.10 machine running and connected to our Windows domain using this package. It’s a great package and it really streamlines the domain membership problem.
Unfortunately there is currently no 14.04 package available in the repositories. The machine we upgraded is currently not able to log in using domain credentials. Since it’s Friday at 16:09, I created the user a local administrative level account and we’ll look to doing more as is necessary (but surely next week).
I imagine this package will appear in the repositories before long. We shall see. Just be forewarned if you are planning to upgrade any Windows domain connected Ubuntu machines any time soon.
But there is a nice delight to offset this. The old vmware-view-client package which was broken due to a misplaced dependency and which has finally been removed from earlier-version repositories has been replaced in the 14.04 repositories with a working version. Now you can use vmware-view-client to attach to your View sessions and you can do so using the VMWare native PCoIP protocol.
Have fun with that.
Recently (not so recently now because I’m a slow blogger) I was installing, or rather attempting to install, the VMware Tools into a virtual machine running Ubuntu 13.04, and I ran into a bit of trouble. This may happen to you too.
First you’ll see this problem:
Searching for a valid kernel header path…
The path “” is not a valid path to the 3.5.0-26-generic kernel headers.
Would you like to change it? [yes]
Enter the path to the kernel header files for the 3.5.0-26-generic kernel?
Clearly no path (“” <— note the lack of… anything) cannot be correct. But how do you find the correct path?
The kernel header path in question should be under /usr/src/[your current kernel version]/include. Of course you’ll need to know your current kernel version. You can find this by running uname -r (it will return something like linux-headers-3.5.0-26-generic). So this is the answer to the above question:
This may yet fail if the headers were not installed alongside the kernel. Sweat not, little piggies! Enter this command to install the proper headers:
sudo apt-get install linux-headers-$(uname -r)
Once that install finishes you can hop back over to the Tools installation and insert the above path once again.
The path “/usr/src/linux-headers-3.5.0-26-generic/include” is not a valid path
to the 3.5.0-26-generic kernel headers.
Would you like to change it? [yes]
Enter the path to the kernel header files for the 3.5.0-26-generic kernel? /usr/src/linux-headers-3.5.0-26-generic/include
The path “/usr/src/linux-headers-3.5.0-26-generic/include” appears to be a
valid path to the 3.5.0-26-generic kernel headers.
Would you like to change it? [no]
I hope that helps you get where you want to be.