Fastest way to updating Xenserver tools and PVS drivers on a Citrix Provisioning image

Whenever there is an updated version of Citrix Provisioning target device driver or XenServer tools, you have to go through reverse imaging on each image to update the drivers. This is very time consuming, especially if you have many images. There is a way to update each image in just a few minutes, and it’s VERY simple.

This method is based on booting the image directly using NFS on the PVS server. Why? Because when you create a NFS share on the same disk as PVS image store, you don’t need to copy anything, just move the file from PVS store into NFS folder and back to PVS store when finished. The good thing is that Windows supports NFS out of the box. Here are 4 commands for you to prepare for this method. On one of the PVS servers run on command line:

ServerManagerCmd.exe -install FS-NFS-Services
nfsshare -o rw=10:0.0.10: root=10:0.0.10: PVSNFS= E:PVSNFS
"c:Program Files (x86)CitrixXenCenterxe.exe" -s -u root
-pw passord sr-create content-type=user type=nfs name-label=PVSNFS shared=true
 device-config:server=pvsserver.mydomain.local device-config:serverpath=/PVSNFS

In above example, replace with IP address from all your XenServers in a pool, replace with your master XenServer IP and pvsserver.mydomain.local with the IP or FQDN of your PVS server.

Create a VM to use for image updates and put the disk of this VM on the shared NFS volume you just created

On you PVS server, open the e:PVSNFS folder. You will see a uniqueid folder. Open it.

Here you will see the uiniqueid of the disk you just created. Rename it as .org or something like this:

We keep the file there just to remember the ID of the file.

Now, go to your PVS image store on the same disk, cut and paste the vhd image you want to update into the e:pvsnfsuiniqueid folder:

Rename the image to the same uinqueid as the disk you created:

Boot the imageupdate VM and update the drivers and tools. When finished, shut down the imageupdate VM.

Rename the image back to the original name.

Cut and paste the image into the PVS store again.

Now you may boot the servers using this updated image.

Repeat the process for each image. Using this process, each image update should take only about 10 minutes.

40 thoughts on “Fastest way to updating Xenserver tools and PVS drivers on a Citrix Provisioning image

  1. Awesome! Much appreciated after some problems around a similar process on NetApp NFS - this was a lifesaver…. Well done!

  2. Hi.
    My VM does bluescreen when booting the copied vhd. STOP 0x7b. Could there be some permissions i’m missing? I need to give administrator rights to the PVSNFS to copy the vhd-file.

    • Yes, that could be. You may have to take ownership of the file and give permissions to it after the upgrade. The NFS share has some special permissions, that the VHD may inherit.

    • As long as there is a hypervisor that supports NFS, this method will work. Physical PVS devices will not be able to use this method.

  3. you are calling “c:Program Files (x86)CitrixXenCenterxe.exe” - and that doesn’t exist if XenServer isn’t installed. any suggestions?

  4. @Cody, you could ignore this line if you don`t use XenServer as hypervisor. In this part of the “script” a softwarerepository for the NFS-Share was created. Just go to your Hypervisor Manager and create a NFS Store.

  5. Not working here. Went from XenServer 6.0 to 6.1 and tried this to update the Tools. When I boot the VM via this method, I can update them and everything looks fine, but when I put it back to PVS, XenServer keeps telling me that the Tools are not installed at all.

    • I’ve not tried using 6.1 yet, will try today. Remember to remove PVS tool, Then xentools before adding the new xentools, you may need 3-4 reboots to complete xenserver tools on 6.1, And Then add the pvs device in the end. Check the ctx knowledgebase for issues with 6.1 tools together with PVS. Check kb article ctx135099. You need fix 09 and 10 for xenserver

      • XenServer is not my primary virtualization product, so I am on a steep learning track 🙂 Update 9 and 10 were already present on my systems btw but I found out how to solve our problem. Removing anything PVS related from the image was not needed. All I needed to do, was delete the target VM’s (not the disk) and then later add the disk again. Somehow, when you update the XenServer tools from 6.0 to 6.1, the VM virtual hardware is altered as well. Thanks for this solution Magnar, is saved me a lot of time and resources. I am surprised Citrix does not advertise this as the primary updating solution.

  6. process worked great, I didn’t create a vm for the update, I just created a new virtual disk and attached it to one of my provisioned xenapp vms. This was quicker and I use the vm to update images normally. One thing I did find when going from xenserver xentools 6.1 to 6.1 with hotfix 10, I had to manually set the platform_device to 002 because this new xentools does it during the install. Since I only did it on my image the vms booting to the vdisk didn’t get this vm attribute set, they showed xentools not installed. After I set the attribute the pvs vm xentools registered properly. This is by far the quickest method.

  7. Can you guys elaborate a little bit on the “platform_device” setting? I googled but can’t seem to find what you mean. Thanks!

    • Nevermind, I found it. For anyone else looking:

      xe vm-param-set uuid= platform:device_id=0002

      It’s in the CTX article that Magnar mentioned above: CTX135099

      Thanks again, this is perfect!

  8. Pingback: Experience with upgrading to Xenserver 6.1 with PVS devices | Virtual eXperience

  9. HI Magnar,
    I followed the article, and booted the VM successfully in my test environment.
    After logging in as a local Admin, I am getting a “Windows created a temporary paging file on your computer because of a problem that occured with your paging file configuration when you started your computer”
    because we had a dedicated additional vDisk (E:) for pvs Write/Cache.

    Other than that, the newly created VM got stuck in amber a couple of times and I had also to do “xe vdi-forget” the nfs vdisk and rescan/reattach.

    But all in all, I love this method! Thanks for posting

  10. Does this method void the .pvp file for the vhd image ? I made all my changes to the image with ease, but when trying to import the image back into pvs I could not do it.

  11. I’ve been working quite a while Provisioning Services, and always been struggling with the uncomfortable re-imaging process. But your procedure is simply awsome!

    Thank you so much for the precise and valuable information! I just did it successfully with a PVS 7.1 SP2 Image running on Xenserver 6.2.


  12. Hi Magnar,

    unfortunately this solution doesn’t work. After “Rename the image to the same uinqueid as the disk you created” when I try to boot vm I get error “The attempt to load VDI failed and when I run sr-scan I get error “SR_BACKEND_FAILURE_40”.

    • It should be working, I’ve been using this exact method many times. Sure you have renamed the vhd file correct, enable “show extensions for known file types” to make sure there is not a duplicate .vhd.vhd ending of the file. I assume you did not rename the store uuid only the vhd uuid.

      • Thanks for quick response.
        I know it should be working 🙂 I did it before but it does not work anymore. I thought that you may had this problem and know the solution. Yes I renamed only vhd file and checked if it is a duplicate vhd.vhd. I also tried to run it from local store on XenServer and the error is the same. I looked on forums to check if maybe this problem has occured after some patch but I have found nothing (I use XenServer 6.2 SP1).

  13. Hi Magnar,

    I created the NFS share on the PVS server and the NFS SR in XenCenter. After that I created a new VM with a disk on the NFS share. When I rescan the Virtual Disks in XenCenter under the PVSNFS SR the scan completes without problems. But after I copied the PVS image to the NFS share and renamed both images the same scan failed with the error “The SR failed to complete the operation”. The permissions of the Original VHD of the newly created VM shows accounts like S-1-5-88-1-0, the PVS image not. But still after replacing the permissions of the PVS image with the permissions of the folder above the rescan fails. Can you tell why the rescan of the disks fails and I cannot attach the PVS disk to the VM?

  14. Interesting, I used to use this process full time, but since upgrading to 6.2, I have the exact issue as above - any progress by any chance?

    • I had this same problem, its tied to the VHD rather than the process/version

      Work around for me, was to take the problematic VHD, and import it via XenCenter into the NFS store that you are using for the reverse imaging - you have to create a VM as part of the import process, but you can blow that away

      I noticed that my VHD changed size significantly but it booted perfectly fine, and i was then able to proceed with the process as usual

      Good luck

  15. It does not work for me with XenServer 6.2 SP1.
    Renaming the VHD gives the same error as above: “The SR failed to complete the operation”
    The issue I believe that is related to the VHD being thick provisioned while the one created by XenServer is thin provisioned. Has anybody tried this?
    I worked around this issue for now by importing the VHD from XenCenter installed on the PVS as I needed to upgrade the XenTools from 6.1 to 6.2.
    For normal upgrades, using the VHD in Private Mode should be fine.

  16. Hi,

    Having the same issue with XenServer 6.2 SP1.
    We don’t use thin provisioning. Looking for the clue but didn’t find it yet.
    I’m now importing the VHD to the NFS SR, but it takes a while 🙁

  17. I get a Tapdisk error when I try to start the VM in XenServer after copying the VHD from the PVS vDisk store. I thought it may be a permissions issue so I used ICACLS to copy the permissions from the initial VHD that created with the VM but this has not helped.

    Any ideas how I resolve this please. I am using XenServer 6.5 SP1

  18. I get the tapdisk error almost every time i do this with a 2012 R2 image. Moving the VM to another storage device (and back if you like) will resolve it, or exporting/importing.

  19. Having the same issue on later releases of XenServer. Our “old” NFS-share, where the .VHD was created using an earlier version of XenServer, I can rename the .VHD and copy another VHD in there and rename it to the name of the” old” VHD.

    However, on newer versions of XenServer the “original” VHD-file gets some very special NTFS-permissions that the file I copy in to the directory doesn’t get, which results in a non-booting VM when using that VHD:

      • I already am the owner of the file, since I’m copying it in there… However, the problem isn’t with the ownership of the file, but the rather strange SID:s having permissions to the “original” VHD file created from within XenCenter, SID:s I cannot re-create in any way. With an older version of XenServer, the “8e2341341-12341234-a7f2341324” directory (different name every time) that is being created doesn’t get these weird permissions.

        Since I can’t put the same permissions on the new file, XenCenter/XenServer refuses to work with the VHD-file. It sees it, but apparently lacks permissions to write to it. And no, “Everyone / Full Control” or even “Guests / Full control” doesn’t help.


Leave a Reply

Your email address will not be published. Required fields are marked *