Windows PV tools

[olivierlambert]

Update by stormi: if you arrived here from README.txt, what you are looking for is probably this: https://github.com/xcp-ng/xcp/wiki/Guest-Tools /end of update by stormi

We can't embed Citrix signed PV drivers. We need to get those from Xen project and document how to install them.

Those "free" drivers aren't signed. We'll probably need to signed them somehow.

You can download them here: https://www.xenproject.org/downloads/windows-pv-drivers/winpv-drivers-81/winpv-drivers-820.html

[olivierlambert]

In fact, they are test signed, whatever it means:

Installing the XenBus Package
=============================

It's important to note that the build scripts generate a driver which is
*test signed*. This means that when the driver is installed on a 64-bit
version of Windows you must enabled testsigning mode otherwise your system
will fail signature verification checked on the next reboot.
If you wish to install the test certificate on the target system then copy
xenbus.pfx (which you'll find in he proj subdirectory) onto your system and
use certmgr to install it. (It is not password protected).

xenbus.sys binds to three PCI devices which may be synthesized by QEMU for
your VM:

1. PCI\\VEN_5853&DEV_0001
2. PCI\\VEN_5853&DEV_0002
3. PCI\\VEN_5853&DEV_C000&SUBSYS_C0005853&REV_01

Device 1 or 2 should always be present: This is the Xen Platform PCI Device.
Some versions of XenServer will synthesize variant 2. All upstream Xen
installations will synthesize variant 1.
Device 3 will be present if you are using QEMU 1.6 or newer and your
toolstack has enabled the XenServer PV Device.
The XenBus co-installer will bind the driver to any of these devices but the
driver will only be *active* (i.e. will only create child devices) for one
of them. If device 3 is present then that will be the active device. If
device 3 is not present then either device 1 or 2 (whichever variant is
present) will be active.

To install the driver on your target system, copy the contents of the xenbus
subdirectory onto the system, then navigate into the copy, to either the x86
or x64 subdirectory (whichever is appropriate), and execute the copy of
dpinst.exe you find there with Administrator privilege.

[necouchman]

In fact, they are test signed, whatever it means:

It's a way of bypassing Windows driver signing, that involves starting up Windows in a certain mode that allows self-signed drivers. We almost certainly want to obtain an official signing certificate from Microsoft and actually sign and distribute them - the process of either enabling test signing or forcing admins to build & sign the drivers themselves is not something I think we want to require.

I've not done enough with Windows drivers to know what the process is of obtaining the ability to officially sign drivers, but we should figure it out and do it.

[olivierlambert]

Thanks @necouchman for being the official maintainer of Windows PV drivers! 🎉

We could pay (with the kickstarter money) for getting those drivers signed, no problem.

[necouchman]

Thanks @necouchman for being the official maintainer of Windows PV drivers!

Haha. I'm certain I'm not qualified for that, but I will try to do some research on what's required to obtain driver signing.

[olivierlambert]

You have repo permissions if you want to upload files in it. Frankly, less I touch anything that's Windows related, better I am.

[necouchman]

From https://docs.microsoft.com/en-us/windows-hardware/drivers/install/release-signing:

Release signing requires a code-signing certificate, also referred to as a Software Publisher Certificate (SPC) from a commercial CA.

The Cross-Certificates for Kernel Mode Code Signing topic provides the list of commercial third-party certificate authorities (CA) authorized by Microsoft. The CA vendors listed must be used to provide a Software Publisher Certificate (SPC) to release sign the driver package.

Here's the list of third-party CAs: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

So, looks like we need to pay for a SPC Certificate from one of those CAs that we can use to sign the drivers. We also need to talk about how we're going to control that certificate and key pair - obviously it's something we need to handle very carefully, and someone needs to maintain it and have it available to create release versions of the drivers. All kidding aside, I don't think I'm the person to do that - I don't have the infrastructure available to build and sign the Windows drivers.

[olivierlambert]

So we need to find someone 😄

edit: thanks for your first research!

[synologic]

Since ReactOS no longer offers free driver signing, you can just get a certificate that's not that expensive. I'm sure the community will help :)
http://codesigning.ksoftware.net/

[olivierlambert]

I may have a solution that will help us to avoid any of this process. I'll keep you posted.

[olivierlambert]

So the solution is to enable the drivers from Windows update, doing a xe vm-param-set has-vendor-device=true uuid=<VM_UUID>. Then Windows update should find an update that will install the PV devices:

Install them and you are OK. Still need the rest of the tools (just the agent, which should be easy to integrate somewhere)

[cocoon]

Is there a limitation when only installing the files from Windows Updates?
I have not verified it yet, but just read this in the release notes:

https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-release-notes.pdf

Customers can now use the Windows Update mechanism to install the I/O drivers (PV drivers) that
deliver enhanced storage and network performance.
In order to install I/O drivers using the Microsoft Windows Update mechanis
m, customers should:

• Ensure the host is correctly licensed
• Create a new Windows VM using the XenCenter issued with XenServer 7.0
• Enable Windows Update within the VM
• Ensure the VM has access to the Internet, or that it can connect to a WSUS proxy server

--->
Customers also wishing to install the full Management Agent (required for VM lifecycle operations or performance monitoring within XenCenter) should install it from the XenServer Tools ISO, or deploy
the management agent MSI file using an MSI installation tool. These files can be found on the XenServer Tools ISO. <---

After installation, the Management Agent will keep itself up to date, if it has access to the Internet.

[olivierlambert]

@cocoon this last part is maybe Open source, but we have to dig. The hard part is to "separate" the management agent from the driver. Can you take a look?

[cocoon]

I will try, just found this:
https://github.com/xenserver/win-xenguestagent

[olivierlambert]

Good catch! I think we should built this and integrate it inside ISO tool.

[olivierlambert]

Pinging @borzel and @stormi

[cocoon]

I made it work with Visual Studio 2017 + Python 3.6.1 here:
https://github.com/cocoon/win-xenguestagent/tree/vs2017

You can build it like this:

set BUILD_NUMBER=0001
set "VS=X:\Programme (x86)\Microsoft Visual Studio 2017 Enterprise"

python build.py checked

For VS2017 Community Edition the Path again seems to be slightly different:
https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

For the Community edition, there's no Build directory in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\

Branding needs to be adjusted in:

src\branding\branding.py

[borzel]

Should I add it to my buildenvironment for nightly builds?

[cocoon]

I am fighting with environment vars, they seem to get lost in my environment (os.environ['PLATFORM'] = 'Any CPU') ... maybe wait a bit or maybe you know python better?

[borzel]

hmm... sounds interessting ;-) Maybe today or tomorrow I have some time to play arround with it.

[cocoon]

found it, wasn't a python problem, there was hardcoded x86 in msbuild.bat, but in the project there is no config for x86.

So I fixed it and now I don't get errors. Can be validated now :)

[cocoon]

Update: sorry, no, I need more time, no error but it doesn't build anymore ^^

[borzel]

Did you install python from cyqwin?

[cocoon]

no cygwin, I am using Python for Windows

It was that in msbuild it needs to be called with x86, but that automatically replaces PLATFORM environment variable with x86, that was previously set by python to "Any CPU".

Have it set again with a custom env var now.

But still to decide if it should be built with vs2013 or updated until it is working with vs2017 ;)

Now it seems to build, but it gives errors like:

Zwischen "Platform:System.Web.Abstractions.dll" und "Platform:System.Web.Abstractions.dll" ist ein Konflikt aufgetreten.  Der Gewinner konnte aufgrund gleicher Datei- und Assemblyversionen nicht bestimmt werden.'

[borzel]

hui ... some nice german errors :-)

[borzel]

We also need this installer: https://github.com/borzel/win-installer

[borzel]

Manual build within Visual Studio works: https://github.com/borzel/win-xenguestagent/tree/vs2017-net461

I will play around more the next day(s)...

[borzel]

I'm about to look into the Windows PV-Tools.

This is was the temporarly "wiki" place for building the windows guest tools - VS2017 is not the right tool...

We need the following repos:

• win-xenbus (https://github.com/borzel/win-xenbus/tree/fix-get-buildable)
• win-xenvif (https://github.com/borzel/win-xenvif/tree/fix-get-buildable)
  • dpinst.exe missing from Win 10 WDK (https://social.technet.microsoft.com/Forums/windows/en-US/0cd9ca3d-8998-4e16-a6fc-61f041d5cf15/dpinst-for-windows-10-build-1709?forum=win10itprosetup)
  • WORKAROUND
    • create dummy C:\Program Files (x86)\Windows Kits\10\Redist\DIFx\dpinst\EngMui\x86\dpinst.exe
    • create dummy C:\Program Files (x86)\Windows Kits\10\Redist\DIFx\dpinst\EngMui\x64\dpinst.exe
  • to check: download redistributable components from WDK 8.1 (https://go.microsoft.com/fwlink/p/?LinkID=253170)
• win-xennet
• win-xeniface
• win-xenvbd
• win-xenguestagent (https://github.com/borzel/win-xenguestagent)
• win-xenvss (https://github.com/borzel/win-xenvss/tree/fix-get-buildable)

Steps for each repo:

• ntddk.h is missing Windows 10 WDK needed - https://go.microsoft.com/fwlink/?linkid=873060
  • KIT=C:\Program Files (x86)\Windows Kits\10
• Upgrade projects on first opening in VS ("Projekt neu ausrichten")
  • upgrade to .Net 4.6.2, Windows 10 SDK, Windows 10 WDK
  • SYMBOL_SERVER=c:\temp
• temporarily adjust DriverVer from 0.0.0.0 to 99.0.0.0 to be buildable
• switch warnings as error OFF
• build with --nosdv (https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/static-driver-verifier)
• Proof-of-buildablilty (manually): build in Visual Studio does not build because of DriverVer == 0.0.0.0, but buildscript does adjust it
• Include fixes for python from @cocoon 👍 , build with buildscripts

The output of the build of these repos goes to

• win-installer (creates the msi which contains all the drivers)

Later:

• Branding :-|

[borzel]

But still to decide if it should be built with vs2013 or updated until it is working with vs2017 ;)

@cocoon I would prefer VS 2017 Community Edition, so everyone on planet can build it

[borzel]

@imtrobin did you clean the VM from artefacts before installing the new drivers?

[imtrobin]

By cleaning, you mean this? https://github.com/xcp-ng/xcp/wiki/Guest-Tools#upgrade-from-citrix-registered-xenserver-registered-client-tools

Yes. I don't have critix tools installed in step1. Removed all installed. No go.

I tried a fresh new win10 Home VM. No go.

[CedSadowski]

I think this time I got the right compilation together, so please test again: https://github.com/xcp-ng/win-pv-drivers/releases/tag/v8.2.1-beta1

Background: Why have the drivers the version 8.2.1 and not 8.2.2?
It was my mistake to take a development state of the drivers. This time I took the stable one's ;-)

Notes:

• general WMI errors, also present with Citrix PV-Drivers, reason unknown

  • call for feedback here: https://xcp-ng.org/forum/post/5785

• xenguestlib: overflow/exception on pointer to int32 conversion (https://github.com/xcp-ng/win-xenguestagent/blob/f4353ff3064d47493821f1c95a5ed46efdf59bf4/src/xenguestlib/Win32Impl.cs#L992)

  • Management Agent and xenguestlib is compiled as x86/32Bit to avoid this (prooved with debugger)

Works perfect on Windows 2012 R2 Standard.

[imtrobin]

test on fresh win10 LTSB 2016 install, still showing "Management Agent Not Installed". It seems to be the same file I tested, did u upload correct file?

[borzel]

@imtrobin did you mean this?: https://github.com/xcp-ng/win-pv-drivers/releases/tag/v8.2.1-beta1

Did you reboot your VM? Do you see the XCP-ng devices in Device Manager?

[imtrobin]

rebooted multiple times.

[imtrobin]

Fresh new VM install. I see windows 10 LSTC is released, will try that.

[De-Occultist]

Just sharing my experience with upgrading to XCP-ng-Client-Tools-for-Windows-8.2.1-beta1 from XenTools 6.2 on a Windows Server 2012 VM imported to XCP-ng 7.6 from an image that was exported from XenServer 6.5.

I did not uninstall the old XenTools 6.2 or do any manual clean up.

1. Run XCP-ng-Client-Tools-for-Windows-8.2.1-beta1\Setup.exe As Administrator, it will be reported with the error message "Windows Management Agent failed to install".

2. Reboot

3. As per troubleshooting guide. https://github.com/xcp-ng/xcp/wiki/Troubleshooting#windows-management-agent--windows-pv-tools

   Start CMD in administrative mode,
   cd C:\Program Files\XCP-ng\XenTools
InstallAgent.exe DEFAULT

4. Tick Trust Vates, Install and Reboot

5. Run XCP-ng-Client-Tools-for-Windows-8.2.1-beta1\Setup.exe again As Administrator then click repair then reboot.

Virtualization state will be shown as I/O optimized and Management Agent installed.

Edit: Added to the wiki.

[olivierlambert]

Thanks for your feedback @De-Occultist !

If you this the Wiki needs an update or more details, feel free to modify it, it's open to contribution!

[CedSadowski]

Thanks for your feedback @De-Occultist

Appreciate.

[imtrobin]

Tried a fresh win10 LTSC, still showing Managment Aent not installed

I installed the agent fine without errors , rebooted, and tried doing this too. Nothing happens.

[imtrobin]

Tested fresh install on win7. Using De-Occultist method, it can install andManagment Agent show it is installed fine.

[MaximumFish]

Tried a fresh win10 LTSC, still showing Managment Aent not installed

I installed the agent fine without errors , rebooted, and tried doing this too. Nothing happens.

Yes, I get the same thing. InstallAgent.exe shows in Task Manager but it does nothing except very gradually eat more and more memory.

[MaximumFish]

After 3 hours bashing my head against the wall on Christmas Eve (it's a production Domain Controller with the issue!) I finally have mine working. I had to:

• Uninstall the XenServer and/or XCP-ng Agents. Reboot.
• Cleanup files and devices as per the wiki above. Reboot.
• Manually delete leftover services using 'sc delete '. Reboot.
• Trawl the registry for instances of 'XenServer', 'XCP-ng', and 'XenVSS' and delete any mention of them, sometimes deleting entire keys related to them. (take a snapshot first!). Reboot.

Once I'd done that the latest beta of the tools installed fine and we're back in business. I considered foregoing the tools themselves and just installing the driver package from Windows Update, which showed up after doing the above, but then you don't get the agent that's needed for memory performance graphing, so I bit the proverbial bullet.

Hope that helps someone!

Edit: As this was a P2V import I also took dsiminiuk's advice and created a new VM from the Windows Server template, unmounted the CD drive, deleted the disk it made, and then attached the disk from the failing VM. I don't know if that made any difference to the end result but during the first boot it did say it was setting up new devices so maybe some things got remapped and ultimately helped.

[borzel]

Gratulations! Just note that the guest tools are in beta state, so you use it on your own risk in production :-)

[Jockz0rz]

For me to get it work I hade to activete "Windows Update Tools" in Xen Orchestra to get it to install.
After I activeted that on start up it told me to reboot and now it's working.

[borzel]

Here is the first version of a little helper tool which (tries to) determines if your host is clean for installing PV-Tools: https://xcp-ng.org/forum/post/9510

[partizanes]

Windows Server 2016 Standard(clean install) and Windows Server 2012 r2(clean install) work by @De-Occultist instruction , but need more reboot (5 reboot) . On 2008 r2 with old xen drivers and agent i tried to clean and install, but it did not work.

[borzel]

It's a complicated thing and I don't have enough time to deal with it alone. I would be happy if someone would join the PV-Tools team to get the work done :-/

[boyejoayo]

Hi @borzel I won't mind assisting you, just let me know in which areas and what needs to be done.
I am a Sys Admin and I run a mixture of XenServer and XCP-NG with XenOrchestra in my infrastructure. I also have a host for test purposes...hopefully I should be able to help.

[partizanes]

So , i tested on windows server 2008 r2 (clean install) and it don`t working correctly.

After install and reboot , system do not boot and show me recovery screen. Then i "Disable Driver Signature Enforcement" and system up. After many steps with manual install drivers and reboot with Disable Driver Signature Enforcement , i see in xcp-ng center I/O optimized,Management Agent installed. After 3 reboot i see agent installed success

But System dont boot without "Disable Driver Signature Enforcement"

[borzel]

@partizanes you have to use our signed (beta) release: https://github.com/xcp-ng/win-pv-drivers/releases

[borzel]

@ayboye I have a need for developers who want to develop/code

[partizanes]

@partizanes you have to use our signed (beta) release: https://github.com/xcp-ng/win-pv-drivers/releases

I tested with signed version (8.2.1-beta1), also i test it on 2012 and 2016 ( all ok) , but it not work in 2008 https://github.com/xcp-ng/xcp/issues/23#issuecomment-492663793 :

Device manager:

Driver detail:

I found diff with windows server 2012:

[borzel]

@partizanes your 2008 screenshot looks ok, all the devices are there. Is your 2008 r2 all up to date? Maybe a cert issue with old root ca's in the cert store

[partizanes]

@partizanes your 2008 screenshot looks ok, all the devices are there. Is your 2008 r2 all up to date? Maybe a cert issue with old root ca's in the cert store

You are right, after updating from windows update, the problem is solved. It is worth noting that I used the latest image provided on the site, but as it turned out there are not enough of a lot of updates.

[sapcode]

Hello guys, great work on xcp-ng!

Just for info this guy has written an auto update script for PV drivers and Xentools for windows:
https://xenappblog.com/2018/download-and-install-latest-citrix-xenserver-tools/

The script calls this url:
https://pvupdates.vmd.citrix.com/updates.latest.tsv

Which points to, no registration needed:
http://downloadns.citrix.com.edgesuite.net/14266/managementagentx86.msi
http://downloadns.citrix.com.edgesuite.net/14264/managementagentx64.msi

Also this looks promising:
https://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers

NOTE: x64 versions of Vista and Server 2008 require signed drivers. The GPLPV drivers are only test signed. In order to use them you need to enable test signing by running "bcdedit /set testsigning on" and rebooting.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option

[borzel]

I made good progress, found a certificate issue. Now the drivers install silently without manuall interaction and they are in Releace Candidate mode now 🚀

Download: https://github.com/xcp-ng/win-pv-drivers/releases/tag/v8.2.2.200-RC1
Please test and report back here --> #181

To keep things organized, I close this ticket.