Provisioning Server and XenServer Interoperability

8 09 2009

While working on a XenDesktop POC this past week I encountered an issue with communication between Provisioning Server 5.1 and the target device client which promptly caused a wave of deja vue.  Could it be the old retry issue that has been around since PVS 4.5 and XenServer 4.1?

As insinuated above by the old product versions referenced, this has been a problem with virtualizing Provisioning Server target devices on XenServer since Citrix first comingled the 2 products.  Apparently depending on the configuration of the network card in the XenServer host a problem can occur with excessive retries on the target device side.  This translates to slow boot times when streaming a VM from Provisioning Server as well as long image capture times when trying to build a vDisk.  It appears to be caused by TCP Offload parameters being enabled on the physical adapter of the XenServer host.

A workaround for the issue is outlined in the following Citrix Knowledge Center article but basically you can set a registry key on the target device side which disables Offloading.

UPDATE: Greg Bulla, a friend of mine and tenured engineer at Old Dominion, shot me an email after reading this post to share some of his personal experiences on this subject.  Upon building a XenServer based guest and executing a capture for a vDisk, Greg encountered the timeout issue noted in my blog.  However, the fix I posted did not address his particular issue. 

After implementing the fix outlined in Citrix article CTX115658, he was able to correct the timeout problem with his VM.  This appears to be another method of disabling Large Send Offload.  The link for this particular article is listed below.  Thanks Greg! 




2 responses

9 09 2009
John R.

Hey Matt – did that turn out to be the issue and did the workaround fix it?

9 09 2009

It was the resolution for the specific issue I mentioned in the blog post regarding the POC. Prior to adding the registry key the vDisk build process was taking over 2 hours which obviously was a big issue as there was only about 3.6GB of actual data to capture. After disabling Offloading it took around 12 minutes.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: