Recently was looking to utilize the vDisk replicator utility (see: https://www.citrix.com/blogs/2017/04/12/vdisk-replicator-tool/) which had a requirement for the PVS powershell snap-in. After a few times did manage to get the snap-in to work but have to be careful to get the syntax correct which was in the end:
C:\Program Files\Citrix\Provisioning Services Console>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil.exe Citrix.PVS.SnapIn.dll
After that was up and running with my replicator
Q came up on the citrix discussions regards this as poster was looking to gather log data for an issue they had with one of their target devices. With version 7 for PVS there was a shift away from using persistent log files to using CDF traces.
More details enclosed
So of course with write cache filling up issues no simple way to tell what’s going on. Needless to say like most quirks that happen in Windows the sysinternals tools can come to you rescue.
Recently started work on a windows 10 PVS image and after about 10 minutes the write cache would fill up.
So using Procmon (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) was able to determine what was going on.
In order though to filter out the extraneous stuff found the following 2 filters gave me info on the offenders.
To do click Filter and filter out everything except write activity by making two filters as follows:
Operation begins with WriteFile Include
Operation begins with WriteConfig Include
and you’ll be on our way.
Check if running Citrix PVS 7.8 or earlier. I’ve had the unfortunate experience of getting this numerous times trying to import an new vDisk version of a VHDX file, unfortunately for me I was running 7.1 at the time and no fix was imminent when I spoke to vendor.
Good news is as of PVS 7.9 issue is resolved.
As per http://support.citrix.com/article/CTX203471 recently was doing a vDisk conversion and was greeted with the message:
“BNIStack failed, network stack could not be initialized”. Fix (tx to good old google again) found via:
This is one of these types of scenarios that you tend to get from time to time but forget what the fix is – must of done this 3/4 times now on different conversions so handy to remember to check your NIC’s!
ESXi VM hardware versions 10 and 11 include a SATA controller for CD/DVD by default. If the SATA and SCSI controller are present on the PVS Target Device, the target will fail to boot. PVS relies on the SCSI controller, SATA is the only one that can be removed. To resolve this issue, change the Virtual Device Node for the CD/DVD Media from SATA to IDE and remove the SATA controller. This must be performed prior to installing the operating system.
To get around this do the following:
i) While creating a new VM from the vSphere web client, under Edit Settings > Customize hardware > Virtual Hardware, change the Virtual Device Node from SATA to IDE for CD/DVD Media.
ii) After selecting the corresponding IDE radio Button, the Remove option for New SATA Controller becomes active. Get rid of it by clicking the “X” at the right hand side of the New SATA controller line
Note: If the Virtual Machine is already created, the mentioned steps should be performed by going to Edit Settings -> Virtual hardware in the vSphere Web Client.
Found this type courtesy of http://support.citrix.com/article/CTX200969 – which also provided info on other issues relating to vSphere 6 and citrix products
This is a little known caveat with the relatively new write cache in RAM with overflow option.
My OS memory is showing all the memory for the VM even though Write cache in RAM with overflow