XenApp 7.13,MCS and VSAN 6.5

[andrew webber1709153696]

Hi, I was wondering if anyone has managed to get MCS working correctly with VSAN 6.5?

When using MCS against a 3 node VSAN cluster I can create a Catalog with no problems, but when the machine catalog update goes to reconfigure the VMs to reconfigure it to support the new image it will produce the following message:-

 

A general system error occurred: PBM error occurred during PreProcessReconfigureSpec: pbm.fault.PBMFault

 

I have cases with both VMware and Citrix and both seem to be saying it is not their fault and not getting far with either of them apart from keep sending VMware log files. I have also built out a number of test environments in a lab using:-

 

XenApp 7.12 (with VSAN Hotfix) against VSAN 6.2

XenApp 7.13 against VSAN 6.2, 6.5 and 6.6

 

These were all vanilla installs and all produce the same message. It is either something very basic that is the issue or a fundamental issue with VSAN and XenApp.

 

The Master Image being used is Windows 2012 R2, HW 13.

 

Any thoughts would be appreciated :)

 

 

 

[andrew webber1709153696]

It seems its relating to the Identity disk being created as a Flat file and the Storage Policy seeing it as an unknown compliancy. Convert the disk using vmkfstools to thin type (think this then converts it as a VSAN object based disk) then all works as expected. Manual workaround though and not sure why this hasn't come up before...

[Lakshmi Srinivas Kommina1709155502]

Hi Andrew,

 

We are also getting the same error.

 

XenDesktop 7.14.1, vSAN 6.5, Windows 7 Master image.

 

I haven't tried converting the disk to thin type yet. Did you managed to find any feasible solution for this other than converting the identity disk for each VM?

 

Thanks

Lakshmi

[andrew webber1709153696]

Hi, we still have a case open with Citrix and VMware. VMware have said they don't support the way Citrix is creating the Identity disk, so I have passed it back to Citrix, which at the moment are saying the issue is with their developers. No time line for a fix. In the end I put a simple script together to sort the disk out after deploying the Machine Catalog. Will drop what I used tomorrow.

[Lakshmi Srinivas Kommina1709155502]

Hi, we still have a case open with Citrix and VMware. VMware have said they don't support the way Citrix is creating the Identity disk, so I have passed it back to Citrix, which at the moment are saying the issue is with their developers. No time line for a fix. In the end I put a simple script together to sort the disk out after deploying the Machine Catalog. Will drop what I used tomorrow.

 

Thanks Andrew. Will wait for your script then. Meanwhile, I will also try to open a case with Citrix for this.

[andrew webber1709153696]

This is what i quickly put together. Just run the script passing a server name. I had a small number of XenApp servers, so didn't need to do anything more. Once the initial deployment of VMs has taken place on the catalog run this against each server before using etc.

 

#MCS VSAN Fix Script

#Converts the identity disk to VSAN object. Stops errors relating to PBM during a catalog update

#Andrew Webber

#Version 1.0

 

#Connect to vCenter first

#connect-VIServer SERVER1

 

 

#Get the VM and store it in a variable

$VMName = $args[0]

$vm = Get-VM $VMName

 

$Datastore = Get-Datastore -VM $vm

$Datacenter = Get-Datacenter -VM $vm

$diskpath = "[" + $Datastore.Name + "] " + $vm.Name + "/"

$vmidpath = $diskpath + $vm.Name + "_IdentityDisk.vmdk"

$vmtemppath = $diskpath + $vm.Name + "_TemporaryStorage.vmdk"

$renameidSource = "vmstore:\" + $Datacenter +"\vsanDatastore\" + $vm.Name + "\" + $vm.Name + "_IdentityDiskOld.vmdk"

$renameidDestination = $vm.Name + "_IdentityDisk.vmdk"

$converthdd = $diskpath + $vm.Name + "_IdentityDiskOld"

 

#Get Disks

#Get-HardDisk $vm

 

#Convert Disk

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_IdentityDisk*"} | Copy-HardDisk -DestinationPath $converthdd -Confirm:$false

 

#Remove Disk

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_IdentityDisk*"} | Remove-HardDisk -DeletePermanently:$true -Confirm:$false

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_TemporaryStorage*"} | Remove-HardDisk -Confirm: $false

 

#Rename Identity Disk

rename-item $renameidSource $renameidDestination

 

#Add Disk

New-HardDisk -VM $vm -DiskPath $vmidpath

New-HardDisk -VM $vm -DiskPath $vmtemppath

[Lakshmi Srinivas Kommina1709155502]

Great. Thanks a lot for the Script. We are dealing with a VDI environment and have to update around 200 VMs. Will try to modify the script per my needs and will post back. Thanks again.

[andrew webber1709153696]

You could replace the $vm = Get-VM $VMName

 

with something like :-

$VM = Get-VM -Location $ClusterName "PREFIX*"

 

Regards

[Lakshmi Srinivas Kommina1709155502]

This is what I used. Just a slight modification to get the list of VMs based on the Machine Name prefix and a recursion to go through all the returned VMs.

 

$VMs = Get-VM -Name "PREFIX*"

 

foreach ($VM in $VMs) {  

$Datastore = Get-Datastore -VM $vm

$Datacenter = Get-Datacenter -VM $vm

$diskpath = "[" + $Datastore.Name + "] " + $vm.Name + "/"

$vmidpath = $diskpath + $vm.Name + "_IdentityDisk.vmdk"

$vmtemppath = $diskpath + $vm.Name + "_TemporaryStorage.vmdk"

$renameidSource = "vmstore:\" + $Datacenter +"\vsanDatastore\" + $vm.Name + "\" + $vm.Name + "_IdentityDiskOld.vmdk"

$renameidDestination = $vm.Name + "_IdentityDisk.vmdk"

$converthdd = $diskpath + $vm.Name + "_IdentityDiskOld"

 

#Convert Disk

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_IdentityDisk*"} | Copy-HardDisk -DestinationPath $converthdd -Confirm:$false

 

#Remove Disk

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_IdentityDisk*"} | Remove-HardDisk -DeletePermanently:$true -Confirm:$false

Get-HardDisk -VM $vm | Where-Object {$_.Filename -like "*_TemporaryStorage*"} | Remove-HardDisk -Confirm: $false

 

#Rename Identity Disk

rename-item $renameidSource $renameidDestination

 

#Add Disk

New-HardDisk -VM $vm -DiskPath $vmidpath

New-HardDisk -VM $vm -DiskPath $vmtemppath

}

 

The updates are working fine after this. However, my vCenter complains that these VMs are now not compliant with storage policies. The storage policies status now is "Out of Date" on all of these MCS VMs even after forcing the policy multiple times and waiting for a long time. The status was "Unknown" before running the script. Any ideas? Are you also seeing the same behavior?

[andrew webber1709153696]

I am not on the environment at the moment. Have you reapplied the storage policies? Also I assume you replaced the "Prefix*" bit with your own value? 

[Lakshmi Srinivas Kommina1709155502]

Yep, reapplied the policies multiple times. Still the status shows "Out of Date" and it happens with every single VM. The PREFIX is replaced with my own value. The script ran perfectly and the Image updates are working fine now.

 

Just to add, I am also spinning off some VMs with Personal vDisk. Had to replace the "*_TemporaryStorage*" bit with "*_pvdisk*" for that particular catalog. Temporary Storage disks are not available for Personal vDisk VMs.

 

Is there any update on your Citrix case by the way?

[andrew webber1709153696]

Ah ok. iirc the storage policy only updates when the VM is off. Nope its still with their developers. I will update once i get an update

[Jason Mills1709152515]

Hi,

 

We are about to deploy VSAN 6.6 with MCS, I don't suppose you have had a chance to test this 

 

https://support.citrix.com/article/CTX219670

[andrew webber1709153696]

@Jason,

 

Yup we did that and in fact i think it made things not work at all. As of 7.15 its still not fixed, but apparently the issue still being worked on between VMware and Citrix. My recommendation is to not use MCS with VSAN at the moment.

[Jason Mills1709152515]

@Andrew,

Ok cool, thanks for that, will chase it up with Vmware and Citrix as well, the more the merrier!  

 

Sadly we are now committed to going to Vsan so I hope they get a fix soon or I might have to consider testing View again :-(

 

We don't do heaps of updates so re-building the catalogs instead of updating them, while a pain, isn't the end of the world.  

[andrew webber1709153696]

Hi Jason, I was in the same situation. The simple script I used seems to work on correcting the issue, so maybe worth doing that. The issue with recreating catalogs, which I found was all the other things you have to consider...i.e DHCP scope IP allocations, AV tools might get duplicates everytime you do a catalog creation etc.

 

I chase Citrix ever couple of weeks, so as soon as I have an update I will let you know.

[Jason Mills1709152515]

Hi Andrew,

 

Ok, thank you very much for that as they are very good things to consider!

 

I don't suppose you have the call numbers that I can reference when I log something as well?  I have run up a lab and am getting the same error so will now log it and have something to show them if I get a callback.

 

I am not much of a script person so looking at the script once i have run it i get 

 

WARNING: PowerCLI scripts should not use the 'Client' property. The property will be removed in a future release.

WARNING: Parameter 'VM' is obsolete. Passing multiple values to this parameter is obsolete.

 

however it seems to work well, do i need to worry about those errors?

[Jason Mills1709152515]

For info my Citrix case no. for this error is 74049326

 

and my Vmware support request no. is 17570201209

[Phil Taylor1709157497]

Has anyone had an update on this we are currently seeing MCS failing on every machine catalog update, we have updated to 7.15 and this issues is still occurring. In a shared desktop environment we could perhaps work around this with scripts, however our customer runs several hindered VDI machines, and they run update several time a week and deleting the catalog and recreating is simply not going to be feasible. I'm very confused from the above are Citrix saving that MCS does not work on the LTSR? This would seem like a fairly fundamental issue! 

[andrew webber1709153696]

Hi,

I did get an email from Citrix yesterday that they might have a specific build fix for me (7.13) and I am just awaiting for them to confirm what it is. The script i posted earlier works around the issue once the VMs are deployed and you don't need to delete and recreate the catalogs once you run the script. Updates will work fine. I have a customer using it fine for the last couple of months.

Cheers

[Phil Taylor1709157497]

good news if they have a fix for 7.13, but still confused how this can creep into the LTSR! When are you running the script? our customer often updates during the morning, and they have a shift change just after midday, this would reboot the machines, and try to update then fail to boot. I would guess that we would have to run the script then which would mean we have unavailable capacity, so i'm not sure if thats going to work? Or are you ruining it periodically? thanks

[andrew webber1709153696]

Hi you just run the script once after you create the VM for the first time as it "fixes" the identity disk. After that you carry out updates as you would do normally. You only need to run the script again if you add machines to the catalog

[Phil Taylor1709157497]

thanks, that might just work! thanks for your help

[Jason Nash1709151307]

Does anyone have a patch from Citrix on this one yet?

[Martijn Hoogenbosch1709156786]

No, but we are running into the same issue. Would be great if someone could provide some timelines.

[Jason Nash1709151307]

Thanks Martijn. I've not heard of a patch as of yet but I don't have my own ticket open with VMware/Citrix on this yet.

 

Do you have this running in production, are you using the script as a workaround at present?