XCP-ng Windows Management Agent
-
Tested and validated!
-
It doesn't work on Windows 7 or Server 2008 R2 for me.
Service cannot be started. The service process could not connect to the service controller - System - Provider [ Name] Xen Guest Agent - EventID 0 [ Qualifiers] 0 Level 2 Task 0 Keywords 0x80000000000000 - TimeCreated [ SystemTime] 2018-08-10T19:22:32.000000000Z EventRecordID 541240 Channel Application Computer RIMAS-SVR.gle.glescrap.com Security - EventData Service cannot be started. The service process could not connect to the service controller -
Please use Markdown syntax for text blocks
``` my text ```edit: I edited your post
-
@CaptGrumpyPants do you have the pv-drivers installed?
-
Hello world!
The firstsecondthird beta of the Windows Management Agent is released
https://github.com/xcp-ng/win-xenguestagent/releases/tag/v7.0.1-beta
https://github.com/xcp-ng/win-xenguestagent/releasesPlease try and report!
Note:
- first read the INSTALL.txt
- it comes without the PV-drivers!
- there is no real installer (yet)
If the service is running
but not functioning 
and windows eventlog shows
"XCP-ng guest Agent cannotfix XenIface WMI interface"Solution: create an additional empty reg key at
HKLM\SOFTWARE\Citrix\XenTools
-
@borzel Yes, I have the Xen PV drivers installed instead of the Citrix PV Drivers. I have noticed that any VMs where the Citrix agent and Citirix PV Drivers (on server 2012 R2) have been replaced will no longer Migrate to other Xcp-NG hosts. Even with the test-signed drivers and Xcp Agent, VMs will no longer migrate. Is there something I am missing here?
-
@captgrumpypants said in XCP-ng Windows Management Agent:
Xen PV drivers
The XEN PV-Drivers do not function complete, because Citrix used for XenServer another PCI-Device number to be different to plain XEN. So the XEN PV-Tools can not functioning
It's by design
-
@borzel Thanks. So which PV drivers and Agent should I use for the time being?
-
The Citrix one, if you have it...
-
So I've been testing XCP-ng since the 7.5 release first came out. It has been my experience the PV drivers are automatically detected and install from Windows. (I have created new windows VMs and they come up already optimized.)
Recently I have been upgrading our servers from XS 7.1 to XCP-ng 7.6. The vast majority took the upgrade, like a textbook and are fine. VMs running either the previous Citrix or the Windows Update drivers and up and optimized without a need to install these packages. EXCEPT (there's always an exception, right?) I have a Windows Server 2012 R2 VM and it doesn't want to play nice. After the Hypervisors were upgraded, and the shuffling was all said and done. this machine will not load the PV drivers. I've tried the "clean your system" how-to, the manual install, drivers RC2 and RC3, even harvested the Citrix drivers in a somewhat creative way and they'll all install, but Windows insists on loading the Realtek driver for the NIC and other 'less than optimized drivers." Like Kirk is ST IV, "I'm going to attempt time travel" to save this whale, by exporting the VM and then importing it into an older version of XS where I can try to install the guest utils properly. Xen won't let you simply "move" to an older version of the server.
The odd part is, I have an essentially Identical VM which went through the upgrade process the same way and it's fine. I also have a Windows 2010 Enterprise VM that survived fine too. This one for some odd reason, isn't.
I have two copies of this server running and I'm trying different solutions concurrently. I'm open to other suggestions.
-
@mpyusko can you short list the steps you did?
Maybe I can guide you to the process...
-
1, Upgrade Pool Master First.
- Disable HA for Pool
- Shuffle all running VMs to another server in Pool.
- Place server in Maintenance mode+, designate new Pool Master
- Mount XCP-ng iso in Virtual Media drive on Server
- Reboot Server to Virtual Media
- Follow Upgrade steps
- Unmount Virtual Media and reboot server.
- Designate as Pool Master
2, Upgrade Subsequent servers in Pool
- Shuffle all running VMs to another server in Pool.
- Place server in Maintenance mode+
- Mount XCP-ng iso in Virtual Media drive on Server
- Reboot Server to Virtual Media
- Follow Upgrade steps
- Unmount Virtual Media and reboot server.
3, Repeat part 2 for all remaining servers in the Pool.
- Enable HA for Pool
+ = I manually shuffle the VMs before placing it in Maintenance Mode. The autmation does ok for a couple VMs but when there are a half-dozen in play it gets a little wonky and fails part way through. You wind up attempting two or three times and restarting the toolstack a few timesbefore they are all "automatically" moved. Manually I can move two or 3 at once to differing servers and get done a bit quicker and less of a headache.
I had 3 servers (Xen 1,2 & 3 we'll call them) in this pool running approximately 20 VMs under XS 7.1. Between the remaining two, I was able to keep them running while any particular Server was being upgraded to XCP-ng 7.6. When I upgraded Xen1, Xen 2 and 3 ran all the VMs from a shared SR. When it came time to upgrade Xen2, I shuffled all the sites off the server onto Xen1. Xen3 wasn'e be messed with. Then I upgraded Xen3 and all the sites on it went to Xen2. After I was done with Xen3, I balanced the VMs out across the pool. It seemed to go smoothly, but shortly after I was done, I noticed alarms going off for one of the VMs (VM2 we'll call it). VM1, 2, 3 and 4 are all windows VMs. VMs 1, 2, and 3 are Server 2012 R2, VM4 is a Windows 10 Ent virtual workstation I use to do all this stuff with. VM4 actually floats around from Pool to Pool depending where I need it and what for. During this process It was running from Local Storage on Xen2 or Xen3. The bulk of the rest of the VMs are Linux based, they all chose to play nice too.
So when I investigated the alarm, it turns out the VM detected new hardware and unloaded the PV drivers and loaded the QEMU, Realtek and so-on. The other VM1, 3 and 4 did not react the same and all still have their PV optimizations even after subsequent reboots. (I couldn't live migrate the VMs, I had to shut them down, move them, and reboot them until all servers in the pool were on the same version)
In an attempt to resolve the issue...
- I tried installing the Citrix Drivers (All other VMs are using Citrix drivers carried over from XS 7.1) That didn't work.
-I found RC2 and the directions to uninstall the Citrix Drivers and install RC2. I uninstalled, cleaned as directed (your directions fail to mention a service needs to be disable in order to delete the last xen file from System32) and instaRC2. That didn't work. - I doublechecked the files and Device manager, and ran c:\Program Files\xcp-ng\XenTools\InstallAgent.exe DEFAULT (cmd as Admin). I got the notice to reboot and followed through. On reboot another notice popped up but it still wasn't loading.
- I rebooted 3 more times (as was mentioned) and still no luck.
- I found RC3 and followed the same process with RC3. Still not luck.
- Now another SysAdmin is working with me and we've tried cleansing the system as prescribed and installing manually. I even found a how-to from a Veeam issue with similar symptoms (https://forums.veeam.com/veeam-agent-for-windows-f33/veeam-bare-metal-recovery-on-xenserver-with-pv-nic-drivers-t48304.html) so I made an edit to a couple registry keys and still no luck.
As of right now, we're still poking around the one copy, while the other copy goes "Time Traveling." (see Previous post).
-
@mpyusko it's important to reboot the vm after you cleaned it well. Just if after cleaning and reboot your vm has the two devices and does not find automatically the drivers... then you are ready to install new ones. It 'svery complicated and complex... I don't know why Citrix has gone this way...Not fun to support such mess...
-
I did try that, but it still did not want to recognize and load the PV drivers properly. The VM is still limping with the realtek divers and. It is performing noticeably slow. Oddly others upgraded without a hitch.
