1. Home
  2. Popular
Log in to post
  • F

    Xen Orchestra web UI becomes unresponsive when an NFS backup remote goes offline

    Unsolved Xen Orchestra
    15
    0 Votes
    15 Posts
    469 Views
    F
    @acebmxer that is exactley what i was saying before. if you disable the remote before nas shutdown you are good on the XO side and will work indefinitely, but if you don't execute umount -l /run/xo-server/mounts/2ab02323-0d47-43a5-9081-b2454e036c70 you will have the mount stuck on the os side. You will be able to reboot XO vm eventually but you will have to wait for a long timeout during XO shutdown. if you want to simulate my issue just disable the remote 5 minutes after shutting down the synology, get the pid from service xo-server status then ps -T pid after a while you'll have 4 "rpc_wait_bit_killable" and XO will stop responding
  • stormiS

    XCP-ng 8.3 updates announcements and testing

    Pinned News
    800
    1 Votes
    800 Posts
    1m Views
    R
    @vxgmichel I may have found our problem. Looks like an XCP-ng update may have slipped an unwanted site back into our /etc/yum.repos.d/xcp-ng.repo. When I first deployed XCP-ng, I had to remove the "http://mirrors.xcp-ng.org/8/8.3/base/x86_64/" entry for updates to work as it was too troublesome to get it working through our outbound proxy managed by another team. I have re-removed that site and things are working again. It was not fun trying to figure that out in the midst of a vulnerability. diff /etc/yum.repos.d/xcp-ng.repo /etc/yum.repos.d/xcp-ng.repo.orig <- baseurl=http://updates.xcp-ng.org/8/8.3/base/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/base/x86_64/ http://updates.xcp-ng.org/8/8.3/base/x86_64/ <- baseurl=http://updates.xcp-ng.org/8/8.3/updates/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/ http://updates.xcp-ng.org/8/8.3/updates/x86_64/
  • D

    XCP-ng Windows PV tools announcements

    Moved News
    119
    0 Votes
    119 Posts
    64k Views
    J
    @Mitchel-APD Thank you! That might acctually help me quite a bit... I have been having trouble getting my ansible-instances to recover from the VM re-initiating the network connection! Perhaps this could be helpfull. I will absolutely test it
  • S

    Backup failures after VHD to QCOW2 conversion

    Unsolved Backup
    5
    0 Votes
    5 Posts
    148 Views
    S
    Thanks for your help! I have the SMlogs from both hosts ready, but they’re too large to upload here, even compressed Whats the best way to share them with you or Team-Storage?
  • B

    New 9.2.445 XCP Windows tools Roll Back

    Management
    2
    0 Votes
    2 Posts
    60 Views
    olivierlambertO
    This is a question for @dinhngtu
  • D

    MFA for console access

    Unsolved XCP-ng
    1
    0 Votes
    1 Posts
    36 Views
    No one has replied
  • F

    [Bug?] Load Balancer: Performance mode fails to power on hosts previously shut down by Density mode

    Unsolved Xen Orchestra
    2
    0 Votes
    2 Posts
    71 Views
    poddingueP
    Your reading of the code matches what I see on master, as far as I can tell. The object.enabled === true check in _getHosts() seems to have come in with PR #10209, released in XO 6.7.1 in August, to stop the balancer migrating VMs onto disabled hosts. If I follow the code right, a host that XO shuts down goes through disableHost first, so the power-on step in performance-plan.js no longer sees it. That looks like a side effect of the fix to me. The docs still say the performance plan powers halted hosts back on (https://docs.xen-orchestra.com/manage-your-infrastructure/load_balancing#plan-modes), so I think one of the two is wrong. I haven't reproduced it and there may be a reason to filter halted hosts that I can't see from the code, so @Team-XO-Backend is better placed to say if your powerState === 'Halted' exception is the right fix.