@peo without deleting, the CBT can fail, but XO can still compute the changed blocks before previous release, the fallback was hidden if you didn't look at the size the CBT issue is on the hypervisor storage side . But at least , the replication issue is fixed, we are back to the good old issues

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

@thomas-dkmt we might need to make sure XO docs tell how system updates are handled and proxy config

@utopianfish Or look for deals in places like amazon.com or bestbuy.com or even Ebay.com.

@olivierlambert said in Migrating logs and history between XOA instances?: Hi, VM stats aren't store on XOA but on your pools, and they should be there with the same history as the old one Can you tell exactly what kind of logs are you talking about? Thanks. I had looked on the wrong VM. The stats are indeed retained. Originally I was thinking of audit logs, but I realized they can be exported and imported. So for m point of view it is enough for now. Other logs that are missing is for example backup logs.

It might record the max static RAM (IDK)

Alright I finally got it to work. I think the trick was to put "Ethernet 2" in quotations. I also perfected the YAML spacing and bracketed the two nameserver addresses. Thanks for the help gentlemen. Final working network config: #network: version: 2 ethernets: "Ethernet 2": dhcp4: false addresses: - 192.168.1.30/24 gateway4: 192.168.1.1 nameservers: addresses: [192.168.1.5, 8.8.8.8]

It is, if you don't use ZFS. ZFS is a memory hog.

@olivierlambert said in Hailo-8L AI accellerator PCI passthrough causes xcp-ng hypervisor infinite boot-loop: Hmm could the module causing the crash if the device isn't accessible? A quick google found this thread on a proxmox forum - according to that user it causes a hotplug event when it initializes. https://forum.proxmox.com/threads/hailo-8-ai-m-2-card-crashes-server-when-using-passthrough.166428/ Seems these AI cards are a bit of a pain - remembering the continuing issue with Google Coral pcie cards

@Kptainflintt you are welcome We are always delighted when we can quickly unblock a user! Have a good day and don't hesitate to come back if you have other issues in the future.

@edisoninfo Great! This warning is a life saver and did perfectly its job, allowing you to discover a hidden issue Glad you found the root cause!

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

@wmazren I had a similar issue which costed my many hours to troubleshoot. I'd advise you to check "dmesg" output within the VM that is not able to get live migrated. XCP-ng / Xen behaves different than VMWare regarding live migration. XCP-ng will interact with the linux kernel upon live migration and the kernel will try to freeze all processes before performing the live migration. In my case a "fuse" process blocked the graceful freezing of all processes and my live migration task also stuck in task view similar to your case. After solving the fuse process issue and therefore making the system able to live migrate the issue was gone. All of this can be viewed in dmesg as the kernel will tell you about what is being done during live migration via XCP-ng.

@bleader just checked the Excel assessment file I got from the security team. They used Crowdstrike (sensor is not installed on xcp-ng hosts). The funny thing is, the asset that it reports as vulnerable is the VM that is running XOA (official image provided by XCP-NG). It is deployed recently, so everything is up-to-date, but even then I don't understand how it reports the XOA VM as the one containing the vulnerabilities.

@olivierlambert did not check that unfortunately, since it it is already setup now, will be hard to reproduce it

@benapetr This is driven by hacky logic from 16 years ago: on revert, unserialize the previous state, and update the VM record with its saved values. As we do not want to modify that each time we add a field in the datamodel, use some low-level database functions to iterate over the fields of a record. Not very nice as it makes some assumptions on the database layer, but seems to work allright and I don't think that database layer will change a lot in the future. I think it might be a good idea to add a revert rpc call to the storage interface that xapi can call to, with a backup to use the current logic if necessary; xapi should be able to clean up the database afterwards. I'll ask other maintainers about this or possible alternatives, but since SMAPIv1 is considered deprecated, I doubt it will happen. I have to say that SMAPIv3 was finally fixed upstream on June by Xenserver (migrations were finally done!) and XCP-ng should get the update that fixes it in the coming weeks. Given this, I would encourage you to take all the learnings you've acquired while doing the driver and porting it to SMAPIv3. SMAPIv1 just simply has too many problems, some of them are architectural, so in general xenserver and xcp-ng maintainers would like to see it finally go away. for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there. 8.2 is out of support for xenserver, and for xcp-ng yesterday was the last day it was supported, you really should update

@Forza I didn't try, as my default Graylog Input was UDP and worked with the hosts... But guys, that was it. In TCP mode, it's working. Rapidly set up a TCP input, and voila. [image: 1758137911306-42411fc9-af86-4838-a870-ca9ca6307234-image.png]

@idar21 @idar21 said in Xen Orchestra 5.110 V2V not working: Don't intend to bump in but the new migration tool isn't working as per the release notes. I had similar issues, there is no warm migration. My testing against esxi v7, resulted in: .Abrupt power off of source VM on esxi. .VM disks start copying. I can see disk copy progress in tasks. .Migration tasks fails but multiple disks of the source VM keeps on copying. .when all the disks are copied, there is no VM with the name available in xcp. .All disks are labeled orphaned under health in xo. .Where is the pause/resume function as stated in the release notes. I don't think the tool has been tested properly. The only difference from older migration tool to this one is progress of disk copying. Otherwise nothing new. The old tool could only do cold migrations and had issues with vms with multiple disks. The new can also only do cold migrations and still has issues with multiple disks migrations. First, I would like to say again that latest can be fresh, and that we know that we ask for our users to be more inventive with latest, in exchange for faster features. Even more for users from source. The documentation is still in the work, and will be ready for sure before this reach "xoa stable". The resume part don't have a dedicated interface : you do a first migration without enabling the "stop source", and then, later you launch the same migration with stop source enabled ( or VM stopped ) and it will reuse the already transfered data if the prerequisites are validated. Then debugging an issue with migration is quite complex, since it's involve multiple systems, and we won't have any access, nor control on the vmware part. It's even harder without a tunnel. I will need you to look at your journalctl and check for errors during migration . Also are the failing disks sharing some specific configuration? what storage do they uses ? Is there something relevant on the xcp side ?

@olivierlambert I use only http for xo-cli, so I didn't understand why I have a CA error. I think it's because I've launched a second XOA for trial testing. Last week, with only one XO, no problem.

That's very clear, thank you for your prompt response!