Latest Entries »

PVS version merge fails


I had a situation where I wanted to merge versions and the resulting version would crash with duplicate IP errors.

What was odd was the fact the address would ping yet DNS and DHCP didn’t have a record for it.  A simple reverse lookup showed nothing.  What worked?

[system.net.dns]::gethostbyaddress("xx.xx.xx.xx")

Might have simply been timing.

After that I attempted to start the management vm and it would die with:

STOP: c000021a {Fatal System Error}
The initial session process or system process terminated unexpectedly with
a status of 0x00000000 (0xc0000001 0x000105a8).
The system has been shut down.

Tried a repair and a reallocation but the same thing happened.

I tried a new version and it worked? I promoted it and it worked.

After that I tried another merge and found it worked.  Strange.

We will have to rebuild this target device as I don’t like odd issues.


As with any Citrix PVS setup; there comes a time you must merge your versions. I tried and received the following error:

There is not enough space on the disk. Error number 0xE0000070

This was a tough error and it was compounded by the fact we used Distributed File System to handle things like the profiles.  This approach was due to the fact we routinely upgrade storage on a three year cycle.

We asked Citrix help and basically they sat on their hands and told us DFS was not supported and we needed to re-engineer our setup to use local RAID storage.  This was not going to happen.

I decided to blame open source and look into not obvious errors. I wondered maybe if part of the merge process was requesting available free space and instead of getting it from storage; it was confused by DFS and taking it from the DFS server itself. A quick total of space used by versions show it was more the the free space available on the DFS server.

We expanded the free space on the DFS server and the merge process worked!

The merge process doesn’t understand links and was defaulting to the free space on the DFS server itself rather then the storage where the versions are kept.

Oh well…..

 


I had a user who reported he would connect to his system at work and the session would go “wonky” with rendering issues.

Going through basic troubleshooting steps did not produce any interesting messages or errors.

Reviewing the Net, I did find a couple Xenapp articles mentioning the same issue and reported there was a fix (KB4039884) to address the rendering problem.  However, I read it was quickly pulled.

Researching a little more; I found that it had been re-released as part of a roll-up.  I went through a couple “replaced by” and found the November roll-up was the latest (at the time I had the issue).  I installed it on my master image (using PVS) and all was good!


I have a new farm with a new VIP.

All the proper firewall rules were in place but access from the Net would only give:

Http/1.1 Internal Server Error 43531

I went through and did all the proper DNS checks, etc., and did not find anything wrong.

The Netscaler had green lights on the basic setup and internally, Storefront was accessible. I reviewed load balancing services and found my two storefronts had yellow lights!

It turns out the security people only updated the firewall rules for one of the firewalls.  A simple update and all was good!

What was strange was the fact we kept hitting the firewall without the rules!  If only I was that lucky with the lottery.

 

 

XenServer CPU information.


A resource pool was transferred and missing where specifics to the cpus.

The command needed for this : lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz
Stepping: 2
CPU MHz: 2600.082
BogoMIPS: 5200.16
Hypervisor vendor: Xen
Virtualization type: none
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 25600K


I had a user report when he uses the Citrix Receiver to access our XenDesktop environment all sessions would reconnect and open windows. He liked XenDesktop but was annoyed by getting all his sessions opened. I explained that it was by design and that the receiver was “helping” him by giving him those sessions as he would need them anyway. He would have none of that. He wanted the control to start as he saw the need.

There is a way to disable this feature. I don’t know if the ability was always present but a newer version of the receiver might be needed. You will know if you follow these steps and the options aren’t there.

What to do:

  1. The receiver should already be installed.
  2. Look on the toolbar to the bottom right for the “^” and click it (this is for Windows 7 and up).
  3. Look for the Citrix Icon which looks like a “C” and right-click it.
  4. Select Advanced Preferences.
  5. Click the Settings Option link.
  6. Click the Reconnect Options tab.
  7. De-select Enable for Workspace Control Support.
  8. Click OK

This will restart the Receiver and should disable the starting of all disabled sessions when a user connects via the receiver. I did have an instance where it required a reboot but that should not be needed.

 


Our new Xendesktop setup solved a few problems and of course introduced new ones.

A user asked the question of how to get gnome to load .Xdefaults automatically as it was not working.

Old software tends to evolve.  Such was the case with Genome.  It now favors .Xresources now.  A quick link and the problem was solved.

ln -s .Xdefaults .Xresources

Citrix VDA version check


I had a question as to the VDA version installed on a Linux virtual machine. I didn’t find anything obvious through the basic ctx commands.

Why not the check the VDA module?

rpm -q XenDesktopVDA

Which in turn showed:

XenDesktopVDA-7.13.0.382-1.el6_7.x86_64

Now let’s see why director is giving me the wrong version information…..

 

 


Minor issue and one of those “DOH!” moments.

Installing a new XenDesktop Delivery Controller. I get as far as creating the connection and my connection address is rewarded with:

The Name Resolver service could not resolve the supplied name.

I checked DNS and sure enough it was there!

The “DOH!” moment?

This is a semi-isolated setup which has it’s own DNS.  The company DNS had the record.

This setup did not.

Oh well!


A brand new XenServer pool in an external office had an interesting problem. Two hosts were added to the pool and yet they could not access two mounts on a NetApp filer.

A repair of the SR would give an error message:

There was an error while attempting to mount the NFS share.

Three other XenServer hosts had no issues.

Checked all the obvious and yet they would not repair. I considered a reload but how would that solve it?

Tried using the mount command to mount one of the shares to a directory and received an error that the server rejected the request.

I mentioned this to the administrator who owned the filer and it turns out he likes to use host lists to control access.

He added the hosts to the list and I was able to repair the SRs.