A couple years ago I was troubleshooting through a Versioning and Merge VHD issue with Provisioning Services (PVS) 7.1 and Windows Scale-Out File Server (SOFS), which resulted in my recommendation to create a Maintenance store for vDisk Versioning. I am happy to see in the last two years this has completely improved and dare I say is fully resolved, specifically with the recent release of PVS 7.7. In this blog post, I’m going to share a little bit of testing data from my experience with PVS 7.7, along with a couple recommendations. Let’s get started!
A couple notes about PVS 7.7 before we begin. If you take a look at What’s New in PVS 7.7, you’ll see a couple highlights that I’ll cover in this blog post:
- In-place upgrade of target device software. Rather than reverse-imaging, you can install a new version of the target device software without having to manually uninstall the previous version. To do an in-place upgrade from version 7.6 to version 7.7 you must first install version 7.6.1.
- Streaming VHDX formatted disks. This feature adds flexibility and efficiency to image and merging operations by letting you stream VHDX files as well as VHD files. Provisioning Services recognizes and uses the file format .vhdx as the extension for base disks and .avhdx for differencing disks (also known as versions). No configuration of this feature is necessary. You perform all image manipulation functions, such as deleting or merging vDisks, or creating new versions, in the Provisioning Services console the same way for both formats.
The in-place upgrading feature is fantastic, and I wanted to call that out before moving on. I won’t be showing any test data from that feature, but my experience with it so far has been fantastic!
For performance testing and results, I’m going to be sharing PVS 7.6 vs. 7.7 and VHD vs. VHDX during image capturing and Versioning merging. The other capability that should be called out as a specific feature of what’s new in PVS 7.7 is the Target Image Creation Wizard and new option to create an image file. This feature allows you to capture directly to a local disk or file share to import directly into PVS. This is actually pretty huge from an admin experience perspective, so I’m not sure why the PVS team didn’t feel this should be called out.
The following is an updated visual of my testing environment. If you compare to my previous blog post, you’ll see I’ve removed the Maintenance Store requirement as this is no longer needed for PVS 7.7 when using with Scale-Out File Server. You’ll also see a couple shadowed SOFS and PVS servers showing the linear scale-out performance for these two components in the architecture:
A couple details about my testing environment:
- Flash volume presented as iSCSI CSV to my SOFS Failover Cluster (high performance)
- Windows Server 2012 R2 for all server components (Two SOFS VMs, two PVS 7.7 VMs)
- 2 vCPU / 4GB RAM for all server components (including PVS to remove possibility of heavy NTFS caching)
- Windows 7 64-bit vanilla gold image (non-optimized) Master VM for capturing. Windows installed, but no applications or updates. Roughly 20GB thin provisioned size.
- 4 vCPU / 8GB RAM for all targets for capturing vDisks
- Continuous Availability disabled for the SOFS Share
- PVS 7.7 GA binaries on servers/targets for any 7.7 tests
- PVS 7.6 GA binaries on servers/targets for any 7.6 tests (no hotfixes or updates)
- All virtual machines are on VMware vSphere 5.5 with VMware Tools installed (using VMxNet3 network adapters)
Continue reading my original blog post at itvce.com…
Very nice and informative article! Thanks.
Great stuff, Dane. Glad you’ve found some of the “hidden” features of 7.7. I have one more to show you that I think you’ll like, too. Should have an article published shortly on it.
PVS 7.1/7.6 you can make VHD files with 16MB block sizes that are supposed to be 4k aligned. What would be the performance difference of these VHD’s vs the VHDX’s?
Great article Dane! Thanks.
Would I somehow be able to convert my current Golden-Images (vhd, Dynamic) to VHDX?
I haven’t tried this, but I suspect it would likely involve reverse imaging the vDisk back to a local hard disk (using %ProgramFiles%CitrixProvisioning ServicesBNImage.exe).
Let me know if you need any pointers on this process.
if you use cvhdmount on the VHDX and VHD images you can use any cloning program you like to do a disk-to-disk. I like http://hddguru.com/software/HDD-Raw-Copy-Tool/ as it’s pretty fast that way.
Great feedback! Thanks Trentent.
Great inspiring article! Thank you for writing this down.
Thanks so much! Glad you liked it.
thank you very much for you article.
I have tested “VHDX Direct” and during standard VM boot got a black screen “Windows error recovery”.
I have selected continue boot and after that VM booted correctly but after first logon I got a screen “Shutdown Event Tracker > Why did the computer shut down unexpectedly?”
I tested it two times with the same result.
Old style VHDX via target client works correctly.
It looks like “VHDX Direct” do something different.
Do you have the same behavior?
Yes, this is my experience as well. Since it doesn’t reboot the target to start the streaming process, it basically comes up in a ‘crash consistent state’. I don’t think there’s anything to concern yourself with here. One clean reboot and you’re back in business.
Thanks for the comment, hopefully this blog post was useful to you!
I never rebooted target to start the streaming process. I just started P2PVS.exe and created new vDisk and the result was without ‘crash consistent state’.
With “VHDX Direct” the process is more quick but with ‘crash consistent state’ 🙂
Do you have in production silo “One clean reboot and you’re back in business.”?
Thank you very much.
Yes, generally speaking a single reboot to a Maintenance VM attached to the vDisk in read/write mode will clean the reboot and you’re back in business!
Do you also recommend to use CIF Share for vDisk Store when not having smb 3.1, for example when using w2k8r2 as pvs Server and accessing Netapp Share?
In General, when using cifs / smb for vdisks, is there any OS System block Caching done in the same
way when a block Level storage (FC SAN, Local) is used ?
Short answer, it depends. I’d recommend you read up on all the caveats and considerations with PVS/SMB 2.1 as covered by the PVS Master, Dan Allen:
Lots more to consider for the older protocols. SMB 3.x+ is a no brainer. Especially now that SoFS works flawlessly as I would have hoped all along.
Hopefully this answers your question!
HI – very informative read. In your SOFS configuration – where are you defining the write cache – on the SOFS cluster?
Very Nice article and informative.