@acebmxer No problem, that's excellent news, thanks for the feedback!

No problem, this is always good to have feedback and cases showing an error and the explanation

@poddingue, that is true, my first post here. I'll try to play with these BIOS settings again. and keep you posted. Cheers

@poddingue Borrow away - "smoke alarm" is a better name for it than anything we had, so we might borrow it right back. Since you mentioned reading the matrix - here is the classification you would be reading, straight from the file: grep access: dadl/xen-orchestra.dadl | sort | uniq -c 49 access: admin 21 access: dangerous 122 access: read 75 access: write 122 of the 267 tools are plain read - that is the entire surface a review-capped agent gets. The other 145 exist in the same file, but for that agent they might as well not. The whole security taxonomy is greppable plaintext - which is rather the point of a declarative format. And if anything in the matrix looks wrong or missing, this thread is exactly the right place - real-world corrections are how it improves.

Hi! It is not the XOCE to xo-server link, it is the credential xo-server uses to log into XAPI on your host. It has to be reversible, not hashed, because xo-server replays it to XAPI on every connect and auto-reconnect. So yes, plaintext by default is expected. The security perimeter here is Redis itself (bound to localhost or a unix socket, never exposed) and root access on the XO VM. That said, since XO 6.5 there is an opt-in encryption at rest. In your xo-server config: [redis] encryptCredentialDatabase = true On the next start, every record is encrypted with AES-256-GCM (values get an enc: prefix) and index keys become HMAC-SHA256 blind indexes, so hostnames and emails are not readable either. The key is split in two halves, one in XenStore (vm-data/xo-encryption-key) and one in /var/lib/xo-server/data/xo-encryption-key. Caveats for a source install: XO must run as a VM on XCP-ng/XenServer with xen-tools, and xo-server needs access to the xenstored socket (root, typically). Config export then requires a passphrase. If you lose one key half while encryption is on, do not restart: XO would regenerate both halves and the existing records would become undecryptable. Full doc: https://docs.xen-orchestra.com/credential-encryption About the PoolAlreadyConnected part, that is a separate issue. It means two server entries resolve to the same pool, typically a slave host registered next to the master, or the pool re-added after a master change. Removing the entry with DEL xo:server:<id> is not the right fix: it drops the hash but leaves the id in xo:server_ids and in the host index. Remove the server from the UI instead. If the error persists, it is the other entry pointing to that same pool that needs to go.

@acomav We will actually propose to change the date and time format in XO6 settings, so you would be able to choose between : YYYY-MM-DD MM/DD/YYYY DD/MM/YYYY and 12h or 24h time format. Hopefully in one of the next 3 months ! I hope that will answer your need, otherwise let me know !

I measured this on a two-NIC 8.3 host. As far as I understand, there's no way to do it from XO: the call that edits a network doesn't take a bond mode, every bondMode in the codebase sits on a create path, and the REST API on a running XOA offers create_bonded_network plus get and delete on a network, with nothing that edits one. The CLI route looks cheap though. xe bond-set-mode on a live bond cost zero dropped packets in both directions I tried, pinging every 200ms across the change, and the command returned in about 1.4 seconds. Two caveats, and the second is about your case specifically: creating and destroying the bond did interrupt the host (roughly 8 and 16 seconds), and I only went active-backup to balance-slb and back, never touching lacp, because my switch port isn't configured as a LAG and I'd have dropped the box. So I can't tell you your lacp to active-backup move is free, only that mode changes in general didn't cost me anything. Worth putting on https://feedback.vates.tech either way so the votes have somewhere to gather.

I went digging and three threads turned up people who already have this hardware. @yeopil21 in https://xcp-ng.org/forum/topic/11799 had an LPe37102-D on a Dell R770 that never showed up at all, @jinju0504 in https://xcp-ng.org/forum/topic/11946 ended up on the -alt package on an R670, and @lukas in https://xcp-ng.org/forum/topic/8847 was running an LPe31002-M6-D with NVMe-oF back on 8.3 beta2. That last one is the older generation, so I'd guess it's the side where you most want to hear nothing regressed. Tagging them in case the cards are still on their benches.

v0.4.0 Release - https://github.com/acebmxer/install_xen_orchestra/releases 0.4.0 - 2026-08-23 Changed The cloud image is staged on the pool master by default instead of being streamed. Staging is the only path that can resume a broken download, retry a transient failure, and check the downloaded size before anything reaches the VDI; streaming can do none of those, because a pipe already feeding a fixed-Content-Length PUT cannot be rewound. On a link that drops the occasional TLS record — which any multi-gigabyte transfer eventually meets — streaming failed every attempt while staging rode it out. Streaming is now what it should always have been: the fallback for a host without the few gigabytes of scratch space staging needs. Fixed A stalled streaming import no longer has to be interrupted by hand. When the download end died, the upload sat waiting for a response XAPI would never send. --speed-time could not help — by that point curl is waiting, not transferring, so the speed meter has stopped ticking and only --max-time 3600 would eventually fire. The two transfers now run as separate processes with the download's exit status watched, and the upload is killed the moment it fails. A pool master short on scratch space no longer fails the whole deploy. The staged path signalled "no room" with a plain non-zero return, which under set -e took the script down before the fallback could be reached. A failed cloud-image download no longer looks like a successful import. The streaming import piped one curl into another, and the remote shell reported only the upload side's exit status. A download that died partway — a transient SSL_read ... bad record mac on a 3 GB transfer is the usual cause — therefore produced a truncated disk that the deploy reported as imported, and a VM that booted into a corrupt filesystem. The pipeline now runs under bash -o pipefail. A broken image download no longer hangs the deploy for an hour. When the download end died, the upload curl had already promised XAPI an exact Content-Length and sat waiting to send bytes that were never coming, with XAPI waiting alongside it until --max-time 3600 expired — the visible symptom being a XAPI task frozen at partial progress and a script that had to be interrupted. Both ends now abort after 60s below 1 KiB/s. The staged image download resumes instead of starting over. It now uses -C - with --retry 5 --retry-delay 3 --retry-all-errors, so the transient TLS failures that a multi-gigabyte single-connection download eventually hits are ridden out rather than failing the deploy. The streaming path deliberately does not retry: curl re-issues from byte 0, and piped into a fixed-Content-Length PUT those bytes would be appended to the ones already sent, corrupting the image while appearing to succeed. A short staged download is refused rather than imported. The file's size is now checked against the length the server advertised before anything is written into the VDI. The staged download reports progress. It was silent for several minutes on the longest step of the deploy, which reads as a hang worth killing. A failed deploy names the VM it left behind, with the xe vm-destroy command, instead of leaving a half-built VM to be rediscovered later in the pool's VM list. Nothing is destroyed automatically. --update/--reconfigure/--rebuild no longer abort on a root install. Reading User= from a systemd unit that has no such line (which is what a root install looks like) failed the pipeline under set -o pipefail and took the script down before the fallback could run. Deploy prompts validate values, not just their shape. 999.999.999.999 was accepted as an address and 70000 as a port; both were only rejected after the VM existed, by an unreachable guest or by the installer inside it. Prompted settings are no longer lost when the base config omits the key. The generated xo-config.cfg was patched with sed, which silently does nothing for a key that is not there — so the VM installed on the default while the summary showed the value you typed. Missing keys are now appended. An $EDITOR with arguments works. code --wait passed the availability check and then failed with "No such file", since the whole string was treated as one executable path. Values edited into the config are validated. An unusable port or branch was silently ignored, leaving the summary showing one thing and the VM installing another. Troubleshooting commands point at a key that still exists. The ssh -i lines printed on a failed install and on a non-200 health check named the temporary key, which the exit trap had already deleted. A second VM with the same hostname no longer overwrites the first one's SSH key, which was the only way into that machine. The disk-space check before staging an image on the pool master is derived from the image's actual size instead of a hard-coded 4 GiB, which rejected small images and let large ones fill /var/tmp mid-download. tests/probe-xapi-deploy.sh acquires its XAPI session from the pool master, the way --deploy does, so a firewall that blocks port 443 from your workstation no longer skips the HTTP transport probes that matter. It also validates --host, --user, --sr, --image and --payload-mb before they reach a shell, drops the eval in the workstation-side transport, and exits non-zero when any probe failed rather than whenever one transport worked. The menu example in the README and the layout comment above MENU_NAMES described the old fixed 5/4/centered grid; with ten items the menu draws five entries in each column. Security The cloud image is verified against its published checksum. The size check catches a download that was cut short; it cannot catch one that arrived complete from the wrong place, because a substituted image has a perfectly consistent Content-Length. The staged image is now checked against the SHA512SUMS its origin publishes beside it — which is what Debian ships — and a mismatch aborts before anything reaches the disk. An origin that publishes no sums warns and continues, so a custom XO_DEPLOY_IMAGE_URL keeps working. Set XO_DEPLOY_IMAGE_SHA512 to require a specific digest instead: that makes the check mandatory, aborting rather than continuing unverified, and refuses the streaming import outright because a pipe fed straight into the VDI leaves no file to hash. Fetching sums over the same connection as the image is not a detached signature — it defends against a bad mirror or a stale cache, not an attacker holding the TLS session for both requests. A pinned pool-master fingerprint is now enforced instead of advised. deploy_verify_host_key fingerprinted the host key and then returned success on every path that could not complete the check — so with XO_DEPLOY_POOL_FINGERPRINT set, a ssh-keyscan that timed out meant the host password was sent to whatever answered on that address, which is exactly what pinning exists to prevent and the easiest outcome for an on-path attacker to arrange. A pin that cannot be checked is now a hard failure. The verified host key is bound to the connection that carries the password. The scanned key was fingerprinted, shown, and then discarded, while dom0_exec connected with StrictHostKeyChecking=accept-new against the default known_hosts — verifying one transaction and trusting another. Nothing stopped a different key, or the host's RSA key when the ED25519 one had been displayed, being accepted at connect time. The whole scan is now pinned into a run-scoped known_hosts that dom0_exec enforces with StrictHostKeyChecking=yes, the same way deploy_wait_for_guest already treated the guest. A hostile pool master can no longer run commands on the workstation. The free-space probe in deploy_import_vdi_staged fed the host's reply straight into (( )), which expands an array subscript before evaluating it — so an answer of PATH[$(...)] executed locally rather than being rejected. It is now checked against ^[0-9]+$ first, matching the guards already applied to size and got in the same function. Note that set -euo pipefail does not cover this: set -u blocks only the unbound-variable form of the payload. This mattered more after staging became the default import path, because the probe went from rarely reached to running on every deploy. The pool master's root password is no longer visible in ps. Three calls predating dom0_exec still used sshpass -p "$HOST_PASSWORD", putting the password in the process list where any other user on the workstation could read it. They now use sshpass -e with $SSHPASS, as dom0_exec does. The admin password hash is kept out of XO_DEBUG=1 output. deploy_harden_guest_sudo and deploy_build_config_drive were missing the local - / set +x guard the rest of the script uses, so the hash was printed by xtrace. Previously masked on automated runs only because --non-interactive left the hash empty; requiring a password made it reachable on every deploy. Revoking the deployment key can no longer empty authorized_keys. A grep failure — no space for the temporary file, an unreadable source — was swallowed by || true and the empty result written back, taking the operator's own key with it. grep's "nothing matched" (a legitimate empty result) is now distinguished from a real error, which aborts and leaves the file untouched. The streaming import's FIFO is created inside a private directory. mktemp -u returns a name without creating anything, leaving a window in dom0's world-writable /tmp. The FIFO now lives in a mktemp -d directory. DSA public keys are rejected. ssh-dss was accepted by deploy_load_pubkey, but OpenSSH has refused DSA since 7.0 and removed it in 9.8, so it only installed a key that silently never worked. The cloud-init cache scrub covers cloud-config.txt. The rendered config holds hashed_passwd just as the raw user-data does; only the latter was being redacted. The deployment SSH key is destroyed at the end of a deploy. It used to be...

@seanmcg182 's post might be the answer to the original question, two years late. Your lspci -s 0000:05:00.0 -v at post 8 shows (rev ff) and !!! Unknown header type 7f, which is the same pair he had, and in his case it came from bifurcating the wrong PCIe port in the BIOS rather than from anything XCP-ng was doing. He says the unknown header is what then produced the device or resource busy error on VM start, which is the error you opened with. I don't know whether your board exposes bifurcation the way his X10DRH-CT does, so it might not transfer at all. @kuznetcoff777 if that machine is still around, it'd be worth a look either way.

After a good sleep, I resolved half of my issue. I got my LSI Cards messed up, I accidentally hidan internal LSI3108 (Address 01:00.0) instead of the PCI Card LSI3008 (Address 05:00.0)... My Boot Drives run off of the internal card. From the fallback kernel, I was able to Modify /etc/grub-efi.cfg to remove the internal card form the hidden list. I now have a separate issue, but will make another post.

Hi, I found your original request. I will make sure someone from the Sales team responds ASAP. Regards, Dan

If i recall from my migration I belive thats all there is to it. I know the docs mention about doing a test migration but mine just migrated and it just worked as you stated after making the needed adjustments. Let other chime in but i think you are good to go. And you could delete the snapshot from the vm.

Very cool, thanks for the feedback @maximsachs !

Hi! No, but check XO logs/output to see what's going on

I'm late to this, but I've been building lately a JetBrains plugin against the REST API and ACL v2 turned out to decide its whole design, so here's some feedback. Everything below is just one appliance, one pool (my small homelab), on a plan 4 trial, with an admin control call taken in the same breath as every scoped one. What I experienced is that selectors narrow reads (tags: and id: both, 1 VM against an admin control of 11), they're re-evaluated per request rather than fixed when the privilege is created, deny composes the way your Carol example says (allow-all plus deny on a tag gave 9, which is 11 minus the 2 tagged), and they scope the power verbs too, not just reads. The event stream is, to me, scoped as well, which was the thing I most wanted to check, because a scoped read next to an unscoped feed would have been a nasty trap. It's not. With two streams open at once, a change to an out-of-scope VM produced an update on the admin stream and nothing at all on the scoped one, so it's genuinely filtered rather than merely quiet. And the bit I'd underline: the same single change is update to the admin and add or remove to the scoped user. The verb is computed per subscriber, not per object. Across that run the admin only ever saw update, and I originally wrote that an admin never sees add or remove at all. That was wrong and I've since measured it: an admin does get add and remove when an object is genuinely created or deleted. So the rule is that a scope change reads as update and an existence change as add or remove, which supports your design better than what I first wrote did. "From the user's perspective, not XOA's" turns out to be literal rather than a figure of speech, and that's a nicer piece of design than the sentence let me imagine. Now the three things that I didn't see in the post above. vm-snapshot is a separate privilege resource and vm doesn't imply it. Maybe that's obvious, but it was not obvious to me. With all six VM privileges granted, GET /vm-snapshots came back empty while admin saw 6, including a snapshot the scoped user had just taken. Anything with a restore or revert screen gets an empty list and no error. Inherited snapshot tags look like a snapshot-time copy rather than a link. Tag a VM and it's in scope immediately, but its existing snapshots keep tags: [] and stay invisible. So someone onboarded into a tag scope after their snapshots exist sees the VM and not its history. Subscribing delivers no initial dump. Both streams sat on init and keepalives until something changed, so it's a delta feed and a client has to fetch the collection over REST and maintain it from events. Worth a line, since the natural assumption (at least to me, don't make that the rule for everyone) is the other one. While I'm here: two smaller ones. Privilege action names aren't REST action names: shutdown:clean grants clean_shutdown, revert-snapshot grants revert_snapshot, and a mistyped action quietly gives you a privilege that grants nothing. And the event: init frame's field is id, not connectionId (why did I think it was connectionId, no idea, I thought it was "natural"), which cost me a while of thinking the stream was dead when I was posting to /events//subscriptions. Yes, I know, I should have read the documentation instead of experimenting in the dark, sending made-up field names in the wild. One last thing: selector is optional, so a privilege created without one reads back as {id, resource, action, effect, roleId} with no hint the field exists. I granted allow read on vm, saw all 11 VMs, read the object back, and (falsely) concluded the REST API had no object dimension at all. It's all in the previous post and it's in the swagger, and of course, in the official documentation. Once again, I'm an innocent victim because I didn't RTFM. I just never saw a privilege that had one. If a privilege echoed selector: null, or if the first example anyone met were a scoped one, I don't think I would have spent much time on that. Once again, my bad, didn't RTFM. This was a small, targeted test, at best. I didn't have the intent to test what was brought up in this very thread, I just happened to tinkle with the REST API and ACL V2 for my PoC, so lots of things got untested. Please, don't take it from me as settled: only tags: and id: selector forms, nothing on a second pool or a real multi-user deployment, and I have not checked what happens to a live subscription when the privilege itself changes rather than the VM's tags. If you read me until there, you're brave, or have too much time on your hands.

Anyone who is using Commvault to back up VMs please tell me what you are using for credintials since you have to connect directly to a pool? I am looking for a way to backup VMs using Commvault and us AD accounts or OIDC.

Hey, that sucks after catching up on 23 commits. Looks like something broke in the log module during the update. I’d try a clean reinstall of the dependencies first, or drop back to an older Node version for a bit since Node 24 can be fussy with these packages. When you need a quick mental break from troubleshooting npm issues, checking out TonyBet is a great way to enjoy some online gaming and sports betting. Hope getting those modules reinstalled gets your build running smoothly again soon!