@michael-manley Sounds fantastic! Should allow for GUI additions flexibility as well.
Posts
-
RE: EOL: XCP-ng Center has come to an end (New Maintainer!)
-
RE: EOL: XCP-ng Center has come to an end (New Maintainer!)
@clip *tracking [as edit button is hidden on my Linux client]
-
RE: EOL: XCP-ng Center has come to an end (New Maintainer!)
@michael-manley Thank you Michael (and patch- and issue-submitters), some clients/users find XCP-ng Center faster for some tasks and like it for familiarity's sake.
Your efforts are much appreciated for making XCP-ng less daunting for a number of people I know - thanks again.
If you are still perchance looking for potential additions, having a (selectable/slide out) right-side of screen (or bottom perhaps) area for showing the running list of tasks (current and history) would make seeing what is going on easier (a quality-of-life issue) rather than switching to it for users (thus making usage and tracing of 'events' faster).
Something like that would be really welcome in XO too !
-
RE: Can xcp-ng utilize TPM 2.0 via passthrough or does TPM only work via vTPM?
@olivierlambert Thank you - appreciate for the confirmation.
-
RE: Can xcp-ng utilize TPM 2.0 via passthrough or does TPM only work via vTPM?
@olivierlambert Thank you, that was my understanding from reading the documentation - in which case, for multiple host / VM migration scenarios, a physical TPM2 chip is of no benefit - and thus not required?
Per: https://xcp-ng.org/forum/topic/7487/vtpm-support-requirements, Stormi (in June of 2023) has confirmed that a physical TPM hardware module is not required for vTPM. I assume, when buying host hardware for Windows VMs, it is correct to count on this for the future as well.
-
RE: Can xcp-ng utilize TPM 2.0 via passthrough or does TPM only work via vTPM?
Thanks for this interesting discussion.
@DustinB In your understanding, does using a built-in chip limit Windows 11 VM (for example) host migrations?
Said another way, is vTPM recommended/required for VMs that will potentially run on multiple hosts?
-
RE: XenServer VM Tools 9.3.3 from Citrix causes bluescreen
@Mt_KEGan Confirming that on my end UEFI is what distinguishes my bluescreening VMs from non-bluescreening (BIOS) ones.
Correspondingly, hardware (Intel i7) may not be the deciding factor (at least for my pools).
-
RE: XenServer VM Tools 9.3.3 from Citrix causes bluescreen
@KPS Updated manually via download and 'automatically' via running the task in Windows Scheduler.
Upon manual update tried allowing the XenServer Management Agent to update both Agent and Drivers - as well as just Agent: both setup attempts bluescreened.
-
RE: XenServer VM Tools 9.3.3 from Citrix causes bluescreen
Confirming issue.
All Windows 10 VMs on one host bluescreen upon update to 9.3.3 (even with toggling XOA option to update by Windows Update off). Used recommended install settings.
9.3.1 and 9.3.2 cause no issues.
Interestingly, all Windows 10 VMs on another host (different pool) have no issues with 9.3.3.
Seems hardware specific: Xeon host fine; Intel i7 host bluescreening.
-
XenServer 8 Released
Looks like it's gone gold today:
"XenServer 8 is now supported for production use, including Windows 11."
- xenserver website (additional info in blog)
Looking forward to XCP-ng 8.3 when ready.
-
RE: Accidental Shutdown Protection Does Not Seem to Work
Yes, totally makes sense. Thanks!
Consequently, best to accomplish the intended behavior from within the Windows VMs.
-
RE: Accidental Shutdown Protection Does Not Seem to Work
xe vm-list params=all
does show the blocked operations as:
blocked-operations (MRW): clean_shutdown: true; pause: true; suspend: true; hard_reboot: true; (unknown operation): true; hard_shutdown: true; clean_reboot: true
Which seems to suggest that clean-reboots are also supposed to be blocked.
Perhaps someone wiser has figured out a cli command that blocks just shutdowns and allows reboots. Would be really ideal if could be applied to all running VMs at once rather than individually by uuid.
-
Accidental Shutdown Protection Does Not Seem to Work
Upon testing in Windows 10 and Windows 2021 R2 clients on XCP-ng, it seems that the XOA setting to prevent Accidental Shutdown does not appear to be working (on latest XCP-ng and latest XOA 'stable' [one month delayed] branch). Selecting Shutdown from the Start Menu shuts down the VM as per usual.
Is this the intended behavior -- or rather is just a Windows restart supposed to be permitted? (Or is the setting supposed to prevent restarts too?)
Perhaps another solution would be if it was there was some cli command that could enable shutdown protection on all VMs in a host pool (and another that disables it on all VMs)? That would resolve the issue for us as well.