Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    5k Posts
    stormiS
    @rzr said: As this is my first time installing these update candidates, Actually we moved first batch of packages that landed in testing to candidates repo, to avoid mix up in the second batch that just landed in testing repo. Since nothing new appeared in candidate you should probably already had them before, home this is clarifying what is actually happening Next yum update should just pull the latest stable versions? Not if you already have installed then from testing (or candidate) repo, because versions are same, it's only the distribution channel that change, no impact for testers. I'm not sure what you understood from @scarfantennae's question, but that we moved packages from xcp-ng-testing to xcp-ng-candidates doesn't seem on topic here. The question is: "now that I've applied this update candidates from the testing repositories, am I definitively in testing mode?". The answer is: no, because: The --enable-repo switch only applies to the two commands you ran: clearing the cache and applying updates. The repositories remain disabled by default, so yes, next time you update you'll only get stable updates if there are any. Either the exact packages that you installed will be pushed as official updates (in which case there will be nothing for you to do), or we'll push newer updates that will supersede them automatically next time you update. Hope it's clear.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    T
    @EddieA Looking at the original crash report, it could be the MWAIT instruction bug that some Intel CPUs have. For troubleshooting purposes, apply this Xen boot option: /opt/xensource/libexec/xen-cmdline --set-xen mwait-idle=false After that, try some reboots/power cycles and let's see if you can reproduce the issue.
  • 3k Topics
    28k Posts
    itservicesI
    Quick Update: Was looking good with commit cf26d. After the transfer completed the VDI of that particular VM was still in use, according to XO. So still failure on the job. Regards, Marc
  • Our hyperconverged storage solution

    47 Topics
    755 Posts
    poddingueP
    Thanks for coming back to close it out. That's useful to know. So I was plenty wrong, as it was the XOSTOR licensing backend rather than the repo side I guessed at; those -32000 errors really don't give much away. For anyone landing here later: sounds like -32000 on XOSTOR creation can come from either end, a licensing/entitlement issue that support sorts, or a host not reaching the package repo, so both are worth checking. @alcoralcor, did support get yours sorted too, or is yours still the repodata / repo-reachability one? Glad you're unblocked either way.
  • 35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !