@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.

@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!

@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.

@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.

@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

@carloum70 One option to address the HA error messages: Delete the HA configuration and re-configure it from scratch once the bonds are all configured OK, which it appears you think they now are.

@ataxyanetwork hey, thanks for sharing this. I am new to the forum so maybe i am not looking in the right place. Your Blog seems to be offline, so did you link the Appliance here in the forum or is it only available on the blog thx

@henri9813 Hi, There should be a new "reclaimSpace" in next release which help you to clean repositories. Just to let you know, we prefer to not remove orphan backups in case a VM removal is accidental and you want to bring back it from a backup repository

@poddingue Turns out it is all secondary-to-secondary out of sync. So that makes it less intense, though if primary dies I wonder how it will resolve this, or if it will become split brained. Still unsure of how it happened, but the ones I manually cleaned up have not come back. Going to continue to manually clear them up. If it happens again I will have an alert setup to notify me, and I have all the xcp-ng logs and everything to be able to see what happened. If that happens I will post here with details and logs for the resource so we can see how it occurs. [image: image.jpeg]

@ronan-a For testing purposes, I did the following: I created a VM on the local SR of a host, installed Linux on it, and configured an ISCSI target. I then added that ISCSI target as an ISCSI SR within xcp-ng pool, and created a small VM on that repository, using XO. While the machine was running, I performed a migration without losing a single ping.I assume this confirms my previous assertion regarding the use of a standard storage system.

Thanks, @Jonathon !

@poddingue Thanks for taking a look. Yes it is this part that tells me that it should start the VM automatically once the import has completed. "After the transfer, the VM on XCP-ng side is started:" Followed by, "This process is fully automated, without any human intervention after it starts on step 1." [image: image.jpeg] https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/ But my findings/experience is that the VM does not start once the import/transfer has completed. So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated". Update: Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration? Because: "Final migration Run the production migration When you're ready for the final migration: Shut down the source VM completely. Start the V2V migration in Xen Orchestra with the Stop source option enabled. This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies." In my mind doesn't state that the VM should be started manually post-transfer. Great thanks in advance for discussing! Cheers!

I wasn't even aware about this being a Windows limitation by itself

Wonderful !

@fohdeesha Hi all, I apologize that it's taken a while to get all the issues sorted, fixed and properly verified. I have pushed the corrected version up to my GitHub, and everything seems to be working much better (thanks to the efforts of everyone here)! A big shout out to all of you, as this is exactly how open source is supposed to work! Let me know if there are any other issues that arrise - and Happy Day to one and All!

@jerry1333 @poddingue First of all, XO and XCP-ng are running very well on all hosts and VMs, and I am using XO-5 without any issues. I have been noticing the same exact issue jerry1333 had, or may still have, with an annoying message that appears just after 30 seconds of connecting to the Xen Orchestra version 6 initial home screen with a Chrome browser (version 153) on my Windows 11 PC. In the past, the error message at the top of the window used to cycle on and off, over and over every 30 seconds. Now, if I don't click on "Retry", the "Unable to connect" message remains indefinitely. Xen Orchestra is up to date: Master, commit fc571 [image: image.jpeg] I consider this to be a mere annoyance, but if I am the only one experiencing this, perhaps someone can give me a suggestion on where to look for a solution. Thank you.

I ran into the same problem with DR replicas. Ignoring VMs by tag would solve the problem, but so would excluding the ip address information.