XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics

    • All categories
    • C

      HA causes reboot of xcp-ng nodes

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Management
      32
      0 Votes
      32 Posts
      766 Views
      tjkreidlT
      @john.c Indeed, John, and I almost forgot that the backup network on each host was actually on a separate, isolated NIC, and not at all on the VLAN.
    • acebmxerA

      Install XO from sources.

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      43
      3 Votes
      43 Posts
      9k Views
      L
      @acebmxer Thank you for your help and prompt response. I truly appreciate it!
    • acebmxerA

      Synchronize snapshots

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      3
      2
      0 Votes
      3 Posts
      51 Views
      acebmxerA
      @poddingue Yes it just make it look odd as it shows itself as a vm being backed up only by the count of vms. Maybe if didnt add to the number it would be fine. Or if there was a description about it in the log or something so when someone is looking in to i like i was dont go looking of for a ghost vm being backed up.
    • J

      Enable Maintenance Mode = Host Not Enough Memory

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved XCP-ng
      5
      0 Votes
      5 Posts
      86 Views
      J
      @poddingue Our HA-pool is a 3 host system, yes. I'll add a note about our plans to go paid in that feedback-item. Thanks for the tip. In the meantime, I'm testing and reporting as much as I can. In order to hopefully help the product be better for all. Cheers!
    • F

      [SOLVED] Just FYI: current update seams to break NUT dependancies

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved XCP-ng
      35
      0 Votes
      35 Posts
      8k Views
      F
      @Kajetan321 I looked into my server and I think I forget some points. First and foremost I have to say, modifying the systemd files can make you system unbootable! It should not happen, but there is chance since we are also modifying some "natively shipped files". So an update can break your working configuration again and that is not the fault of XCP-NG!!! That said I assume that after a reboot (prior to any of any input of yours) if you enter: systemctl status ups-driver.service nut-server.service nut-monitor.service you will see that "ups-driver.service" is loaded and active, but the 2 other services are not. If thats the case I think I can help you since it is related to a dependency problem during boot up. Please do the following: Remove "nut-driver.target" dependency from "nut-server.service" by calling nano /lib/systemd/system/nut-server.service and remove nut-driver.target from routine. I prefer to duplicate and comment the to be modified rows to keep the original code. It then should look like this. DO NOT COPY AND PASTE, read, compare and modify carefully! [Unit] Description=Network UPS Tools - power devices information server #After=local-fs.target network.target nut-driver.target After=local-fs.target network.target # We don't Require drivers to be successfully started! This would be # a change of behavior compared to init SysV, and could prevent from # accessing successfully started, at least to audit a system. #Wants=nut-driver.target Wants= # The `upsd` is a networked service (even if bound to a `localhost`) # so it requires that the OS has some notion of networking already. # Extending the unit does not require *this* file to be edited, you # can instead drop in an additional piece of configuration, e.g. add # a `/etc/systemd/system/nut-server.service.d/network.conf` with: # [Unit] # Requires=network-online.target # After=network-online.target Requires=network.target Before=nut-monitor.service PartOf=nut.target [Service] EnvironmentFile=-/etc/ups/nut.conf SyslogIdentifier=%N # Note: foreground mode by default skips writing a PID file (and # needs Type=simple); can use "-FF" here to create one anyway: ExecStart=/usr/sbin/upsd -F ExecReload=/usr/sbin/upsd -c reload -P $MAINPID [Install] WantedBy=nut.target Afterwards enable nut.target: systemctl enable nut.target Then call: systemctl daemon-reload systemctl start nut.target systemctl start nut-monitor.service Now it should work even after reboot
    • marcoiM

      XO Tasks - backups just pilling up

      Watching Ignoring Scheduled Pinned Locked Moved Management
      1
      1
      0 Votes
      1 Posts
      22 Views
      No one has replied
    • D

      XCP-ng Windows PV tools announcements

      Watching Ignoring Scheduled Pinned Locked Moved News
      115
      0 Votes
      115 Posts
      42k Views
      Y
      @dinhngtu Received the following feedback from Bitdefender Enterprise Support Team (as expected): We can confirm that the file is clean and is currently not detected by our engines.
    • J

      PCIe Pass-through lanes and lane performance

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Compute
      51
      0 Votes
      51 Posts
      9k Views
      pandusenP
      @stormi I dont doubt that the team works hard. The GPU passthrough support has been of lower priority for a long time, it has been said many times before by the team and Oliver. 99 percent of the dev team is working security and basic hypervisor, and is not prioritized for edge cases. Which i guess that PCI passthrough is for GPUs Please dont ask me to dig up the sources. It has always been the case with Xen.... Proxmox, KVM and vmware has the edge there, and that should be well known. But I would in any case where PCI passthrough for edge cases like the GPU marked kind of is, is not a requirement, Always recommend XCP-ng over the others.