Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    D
    @abudef An overhaul of the guest agent is coming. We're considering adding some kind of update notifications as part of that overhaul, but it'll take some time to suss out the details. Autoupdating the Xen drivers is potentially disruptive and I'd prefer avoiding outages arising from an update coming at a bad time.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Honestly, the confusion makes total sense; GitHub does a great job of hiding this stuff. Here's what's going on: those markdown files only exist right now as a proposed change sitting on a branch. That's the whole reason you can only get to them through the pull link, and nowhere else. They become a real, permanent part of the repo the moment you merge them in. And since it's your repo, that merge is yours to do, no special GitHub-fu required. Open the PR page (https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection/pull/1), scroll down a bit, and click the green Merge pull request button. That's the "commit" step you were asking about. There's one wrinkle worth knowing about, and it's the real reason none of this shows up on your main repo page. Your repository has a couple of branches. Your existing PDFs and the Word doc live on a branch called XenServer-Articles, so I pointed my PR at that same branch to drop the markdown right next to them. But the page GitHub shows when someone visits your repo is a different branch called main, which at the moment only holds a README. So even after you merge, the articles will sit on XenServer-Articles, not on that front page. That's actually been true of your PDFs all along; it's nothing my PR changed. If you'd like the articles to show up on the landing page too, there are two easy ways, and I'm happy to do either one for you. We can change the repo's default branch to XenServer-Articles in Settings > Branches, so that one becomes the front page. Or I open a second small PR copying everything over to main. Just tell me which you'd rather have. So the short version: merge the PR to make the markdown real, then we can decide whether you also want the front page pointing at the articles. No rush at all on that second part. gounthar opened this pull request in tobiaskreidl/Citrix-Tobias-Kreidl-Collection open Add Markdown versions of the three articles (render inline on GitHub) #1
  • 3k Topics
    28k Posts
    J
    @dinhngtu said: I've taken a quick look, looks like it'll be solved as part of the Windows guest agent overhaul, so please look forward to that. Thanks for the info. I will be looking forward to that, indeed.
  • Our hyperconverged storage solution

    47 Topics
    746 Posts
    poddingueP
    This is a tricky one, and I'm a bit out of my depth on the XOSTOR internals, but the pattern you describe (XO losing the pool for 30 to 60 seconds while SSH and ping to the hosts stay perfectly fine) reads more like XAPI stalling on a storage call during the LINSTOR coordination than a real network drop. One detail caught my eye: you mention XOSTOR is on the 10Gb storage network only. The XOSTOR docs actually recommend the satellites stay on the XAPI management interface and call a dedicated network for them "not recommended" for pool robustness (https://docs.xcp-ng.org/xostor/), which feels counterintuitive with a fast 10Gb link sitting right there, so I may well be misreading your setup. If you're able to grab /var/log/SMlog and /var/log/xensource.log on the master host during one of the disconnect windows, that should show whether XAPI is timing out waiting on a storage operation. Nobody's chimed in yet, and this is pretty XOSTOR-specific, so it might be worth a mention to @Team-Storage; they'll know far more than I do about whether the satellite-network config is what's triggering it.
  • 35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !