administrators

Private

Posts

  • RE: Slow boot on rocky linux 10 latest kernel

    Thanks for actually booting one, that's the bit I skipped. 🤷

    -84s versus -10s without console=ttyS0 matches the Ubuntu ratio, and it's the first EL10 number anyone has measured rather than read from the source. 👍

    That settles the question I left open. A real-world measurement is vastly better than a source-code read, right?

    Thanks for the backport request, too. Since CentOS Stream sits upstream of RHEL and Rocky, if the backport lands there, it should be the earliest signal that the rest of the family will follow. 🤞

  • RE: Backup failures with odd connection refused errors

    Thanks for the feedback. 👍

  • RE: Bringing container visibility back to XO

    I went and checked a couple of the factual bits here rather than take them on trust, and the xscontainer one holds up: xscontainer-10.0.4-1.xcpng8.3.noarch.rpm is still sitting in the 8.3 base repo, and back in topic 6845 Olivier said it was meant to be removed at some point, which evidently hasn't happened.

    The wiki page is the bit I couldn't reproduce. There's no Docker or container page in the current docs that I can find, and nothing matching in the docs repo either, so I might be looking in the wrong place. 🤷

    On the proposal, I'm not the right person to say whether a containers collector fits the agent's scope. Two things I can tell you. xen-guest-agent lives on GitLab rather than GitHub, so the design conversation would need to happen there. And there's no Feeder entry for any of this yet, which surprised me given how far back the requests go; worth putting one up so the votes have somewhere to land.

    That's my read on where it should go rather than on whether it's a good idea, and someone closer to the agent will correct me if I've sent you the wrong way.

  • RE: XCP-ng 8.3 updates announcements and testing

    Hello @MajorP93,

    Several things in your message raise questions for me.

    First, this SR:

    • 1x Linstor vSAN iSCSI configured as QCOW2

    What is this storage and how is it configured?
    Currently, we do not support QCOW2 on Linstor/Xostor. So, is it simply an iSCSI device to which you have applied the QCOW2 format, or is it a Xostor on the XCP-ng pool?

    Regarding jumbo frames, we do not use them internally and are not currently testing them. It is often recommended not to use them for the management interface, as indicated in the XCP-ng documentation: https://docs.xcp-ng.org/networking/

    Non-standard MTUs (such as jumbo frames) are not supported on management interfaces. Using them can lead to serious issues, including failed pool member joins or unexpected network outages.
    

    Is that the case here?

  • RE: Slow boot on rocky linux 10 latest kernel

    Rocky 10 is affected and has no fix in it. I pulled the source RPM for kernel-6.12.0-211.16.1.el10_2.0.1, which is your -211: jiffies.c still ends on core_initcall(init_jiffies_clocksource) with no cs_jiffies_registered, so f24df84cbe05 hasn't landed, and max_raw_delta sits in clocksource.h with nothing setting it early, so the regression is still there.
    So tsc_mode=2 and nomigrate stay the answer on Rocky until Red Hat picks it up. 🤷
    One more thing, because this thread reads like an AMD problem if you skim it. @dvinni measured the same stalled clock on Intel Xeon Gold in the sibling thread, and the upstream fix came from @teddyastie bisecting it on a Xen HVM guest. I read source rather than booting a Rocky VM, so if you have one behaving differently I'd like to hear it.

  • RE: Veeam 13.1 Rocky9 Linux Appliance: Potential Data Loss with CBT and Workers with Expired Tokens

    Nothing from our side that I can pass on, sorry.
    Two public things I can point at, neither of which I've tested against your case: the updates that went live yesterday list tapdisk crash fixes among the storage changes (https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/), and there's an open PR on tapdisk picking up a cbtlog disk during commit and failing early because that driver has no commit action (https://github.com/xcp-ng/blktap/pull/17).
    I'm reading a changelog and a PR body rather than reproducing anything, so treat both as leads.
    @msupport, Danp's three questions from 6 August are still open (guest OS, guest tools, VHD or QCOW2), and filling those in is probably worth more than anything I can add here.
    @dsauce, I don't know the answer to yours about CBT and the leftover veeamsnap VDIs, and I'd rather say so than guess on a thread about data loss.