-
@stormi The strange thing is, I had to turn off the VMs, rescan disk and then turn on again.
The coalesce process began with the linked VMs (in production) and successfully completed. The following values have been changed at /opt/xensource/sm/cleanup.py :
LIVE_LEAF_COALESCE_MAX_SIZE = 1024 * 1024 * 1024 # bytes LIVE_LEAF_COALESCE_TIMEOUT = 300 # seconds
Well, apparently everything ok... we will see in our next backup if it will be necessary to turn off the VMs for the coalesce to start and complete correctly.
-
@stormi After the informed change, the backup occurred with 100% success, on no disk in the coalesce chain.
We're migrating another cluster to XCP-ng 8!
Thanks for the support, quick return and attention. -
A new update just pushed for XCP-ng 8.0:
xcp-ng-xapi-plugins
. It adds a plugin that the latest version of Xen Orchestra (just released) needs in order to offer a new feature: integration ofnetdata
for all hosts into a single interface. See the blog post.If
xcp-ng-xapi-plugins
is the only update available for your hosts, then no need to reboot after installing. A toolstack restart is enough.If you don't need the new feature, you can skip this update until the next batch.
-
New security update candidate for testing in XCP-ng 8.0 and 7.6.
Fixes security issues in Xen. Also provides updated microcode for some Intel
Details and discussion on https://github.com/xcp-ng/xcp/issues/319
Please test (we simply need people to install them and check that they do not see obvious regressions).
-
-
This post is deleted! -
This post is deleted! -
Hi
I've a problem with freezing Windows VMs after applaying latest updates - do You know anything about it? Those vms have guest tools from citrix.
-
I haven't heard of it until now.
-
@akurzawa I also experienced an issue after the update as well. After the host rebooted and I tried turning on a Windows 10 VM it hung on the Windows boot screen.
-
I eventually force rebooted
-
Force shutdown + Change CPU and RAM (not sure if the resource adjustments helped of not)
-
Start VM and it came up in Windows recovery mode
In the windows recovery mode I just exited and it continued the boot process. This time it booted successfully but I was greeted with the below message upon login.
I had to use XCP-ng center to use keyboard shortcuts to select yes on the dialog box as mouse input was not working. After the restart everything is working as usual again.
I also have the Windows Updates based guest tools enabled on this VM.
@stormi I think this has to do with the new version of guest tools Citrix has pushed from their release of CH8.1. Checking the services they now show major version 9. Not sure if @akurzawa is facing the exact same issue or a variant of it?
-
-
This smells like windows pv drivers upgrades. Had similiar effects on various VMs.
-
FYI: https://support.citrix.com/article/CTX235404
"Important: Updating to this version of the driver removes the quiesced snapshots capability of the VM. If you are using quiesced snapshots and wish to retain this functionality, do not adopt these 9.0.0.x drivers."
They do not tell about crashing VMs though
-
Citrix also has a long history of problematic VM guest-tools. Race conditions with broken drivers, unbootable VMs, broken agents... It's a pain in the a**.
If you like your VMs: Always make a snapshot of every VM before updating the tools.Is known why they remove the VSS-functionality? I don't get why they remove features (again).
-
@stormi said in Updates announcements and testing:
FYI: https://support.citrix.com/article/CTX235404
"Important: Updating to this version of the driver removes the quiesced snapshots capability of the VM. If you are using quiesced snapshots and wish to retain this functionality, do not adopt these 9.0.0.x drivers."
They do not tell about crashing VMs though
I read the support article hoping for more details on how to "...retain this functionality, do not adopt these 9.0.0.x drivers." but the article does not mention that either.
I did not opt to install the new guest tools at any point. I only shutdown the VM to complete the host patches.
Also see the image below, unless it installs guest tools through a side channel that does not show in the Windows updates history.Would simply disabling the "Windows Update tools" advanced option in XOA/XO stop it from adopting the new guest tools?
-
I have pushed an update to the
netdata
andnetdata-ui
packages.No need to reboot after installing it even if XO tells you so.
It fixes an upstream issue where in some cases the cache size on disk grows indefinitely without respecting the 256M default limit (reproduced only internally but I don't want to take a risk). Only
netdata-ui
is concerned. If you are using netdata through XO, then there's no risk for your hosts. Now netdata will only store 1h of data in RAM, nothing on disk. -
I have pushed an updated
bnxt_en
driver asbroadcom-bnxt-en-alt
for 8.0 and 8.1. It is inxcp-ng-testing
for 8.0. If fixes a very specific issue from what I can see in the code diff, so no need to install it if everything is already OK for you. -
By the way, is anyone interested (and why) in updated drivers for cisco-enic and cisco-fnic?
-
This post is deleted! -
This post is deleted! -
First update for XCP-ng 8.1:
xcp-ng-deps
for pulling thegpumon
package. That issue has kept us busy this week when people started reporting installed or upgraded systems that would be unreachable from XO and XCP-ng Center after a reboot. Turns out that XAPI needsgpumon
, a package that can only be built using a proprietary (from what I remember. One would need to check the license) nVIDIA developement toolkit. I had removed it from XCP-ng 8.1 because I was convinced that it was only necessary with thevgpu
feature with nVIDIA, and we don't have thevgpu
package in XCP-ng because it is closed-source. XAPI's start process stalls without an error message if there's an nVIDIA GPU. Installing gpumon fixes it.- after the update: if you were affected by the issue (you would know), you may need to do an emergency network restart and possibly reconnect the SRs. There may be other consequences for the hosts, such as missing removable media from VMs and possibly others. If you have a way to come back to a backup and reinstall with the fixed ISO (released 2020-04-06), this may be the safest path.
- see also https://github.com/xcp-ng/xcp/wiki/XCP-ng-8.1-Known-Issues#host-unreachable-after-upgrade-or-fresh-installation-on-hosts-having-an-nvidia-gpu
xcp-ng-release*
for reducing chrony-wait's timeout from 600s to 120s. So if your host can't connect the ntp server that was configured at installation, you'll only have to wait for 2 minutes, not 10. But your hosts really should be able to connect a ntp server. Accurate time is required to avoid timing and synchronisation issues.
No reboot required if your host is already behaving correctly. If you have a discrete nVIDIA GPU and the host had no issue, then 1. I'm surprised, 2. I advise to reboot.
New installation ISOs including those two updates will be released shortly. 2020-04-06 update: they have been released, named
xcp-ng-8.1.0-2.iso
andxcp-ng-8.1.0-2-netinstall.iso
.As ususal, see https://github.com/xcp-ng/xcp/wiki/Updates-Howto