administrators group | XCP-ng and XO forum

poddingue

@JamesG, I'm the one who marked it solved, so here's what I meant.

What Teddy showed in https://xcp-ng.org/forum/post/109066 is that there's one thing to do on the XCP-ng side for the B50: turn HVM PIRQ off for that VM (xe vm-param-set uuid=<vm-uuid> platform:hvm-pirq=false, then reboot the VM), as described on the docs page he linked: https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7.

With that, his benchmark came out normal for the card, and the Gen1 x1 you see inside the guest is something QEMU makes up, not the real link (his earlier post: https://xcp-ng.org/forum/post/106479). It doesn't mean every problem is on the guest side though: @pandusen tried the same setting (https://xcp-ng.org/forum/post/109084) and still had driver crashes on headless distros, and I don't know why. If you try it on your B50 and post what you see, that would help tell the two cases apart.

poddingue

Glad it's working, and thanks for posting the script, the next NUT user will want it (I hope I'll be able to experiment with NUT in the coming weeks, so I could very well be "the next NUT user").

I tried the PBD part on a lab host running 8.3: xe pbd-list never prints a storage-type line, so that grep finds nothing and step 2 quietly unplugs no PBDs. The 2>/dev/null hides it, and --force isn't an option pbd-unplug knows about. My wild guess is that ejecting the CDs is what fixed it for you.
If you want the unplug to really happen, going through the SR type works on my side, though I only tested it against an ISO SR, not SMB:

H=$(xe host-list hostname=$(hostname) --minimal)
for t in nfs smb iso lvmoiscsi; do
  for sr in $(xe sr-list type=$t --minimal | tr , ' '); do
    for pbd in $(xe pbd-list sr-uuid=$sr host-uuid=$H currently-attached=true --minimal | tr , ' '); do
      xe pbd-unplug uuid=$pbd
    done
  done
done

Block iSCSI SRs show up as lvmoiscsi, which is why it's not iscsi in the list. @Forza's point about hard mounts may still bite if the share is already gone when the unplug runs; I don't know enough about the SMB side to say.

poddingue

@jr-m4 since my last post I ran the whole thing through XO to be sure. Two VMs, each with nothing but an empty 2 MiB disk, same delta job: the UEFI one passed its health check in a few seconds, and the BIOS one failed after the 10 minute timeout waiting for the guest tools, which is what the docs promise.

So that sentence only holds for BIOS VMs, and your case of a rarely used VM with a bad disk is where that matters. I've passed both results to the XO team, though I don't know yet whether they'll change the check or the docs. Until then, the xo-backup-health-check-xenstore tag I mentioned earlier is the way to make the check depend on something actually running inside the VM.

poddingue

@dknight-bg the Feeder post you linked asks for two things: sending audit events to syslog, which is what this PR does, and recording successful logins, which as far as I can tell the PR doesn't touch.

If others reading this need either one, a vote on https://feedback.vates.tech/posts/88/audit-log-forward-events-to-remote-syslog-record-successful-logins is the easiest way to show it. The PR is still waiting for a reviewer, as far as I can see.

poddingue

Okay, I moved it...

poddingue

Thanks, @DustinB, this looks useful to me.

Back in https://xcp-ng.org/forum/topic/7662 @VGerris wanted to build an OKD recipe for XO, so at least one other person has been after this.

I haven't run through it myself, so I can't vouch for each step, but keeping the workers off until the bootstrap node is out of HAProxy looks like it saves people a confusing HTTP 500.

It's in Off topic at the moment, would you mind if it moved to Infrastructure as Code? I think that's where people looking for OpenShift on XCP-ng would search first.

poddingue

@pandusen, I understand your frustration, but please focus on the content, not the person. Also, note that the request for dmesg output came from @MajorP93.

@john.c, if you use a tool, please check its commands before posting, and try to keep your posts shorter.

On the content: step 1 of @john.c's advice is xen-cmdline --set-xen "pci=realloc", and that part is wrong. AFAIK, Xen's pci= option only accepts serr, perr and quirks (Xen command line docs); realloc isn't a valid Xen option. pci=realloc is a Linux kernel option, right?

It's okay to be wrong; I often am too. The important thing is not to be overly assertive when you're not sure you have the right answer.

Teddy's answer is sound, which is why I marked this thread as solved. However, the thread isn't locked, so it remains open for the Arc and ReBAR follow-up.

Thanks, folks, let's keep a friendly and helpful atmosphere.

administrators

Posts

Member List