thanks for advice, i'll keep my minIOs running

how come you get the mac address ? I'm using NetBox Community v4.3.7-Docker-3.3.0 with latest XOA ps : little bug, if you COPY a VM, the netbox plugin will throw an error 400 i guess, for duplicate IP address I just have to change one bit of the mac address of copied VM and the netbox sync will be OK so it checks the mac address... but do not sync it in my netbox

@okynnor IIRC, it would take a reboot before the problem showed up. I'd check after a reboot if XenSvc wasn't stuck in the starting state.

@hitechhillbilly Hi, For now the import tool does not use the proxy. Not that the full import tool also work from source if you need additional XOA , but we won't be able to connect to them for support

@dinhngtu said in Epyc VM to VM networking slow: @Forza There's a new script here that will help you check the VM's status wrt. the Fix 1. Thank you. It does indeed look like the EPYC fix is active in XOA. [07:25 22] xoa:~$ python3 epyc-fix-check.py 'xen-platform-pci' PCI IO mem address is 0xFB000000 Grant table cacheability fix is ACTIVE. Has Vates checked if a newer kernel would help the network performance with XOA? Current kernel is: linux-image-amd64/oldstable,now 6.1.148-1 amd64 [installed] When trying to install any of the newer kernels (6.12.43-*) it immediately fails dependency check: [07:30 22] xoa:~$ apt install linux-image-6.12.43+deb12- linux-image-6.12.43+deb12-amd64 linux-image-6.12.43+deb12-cloud-amd64-unsigned linux-image-6.12.43+deb12-amd64-dbg linux-image-6.12.43+deb12-rt-amd64 linux-image-6.12.43+deb12-amd64-unsigned linux-image-6.12.43+deb12-rt-amd64-dbg linux-image-6.12.43+deb12-cloud-amd64 linux-image-6.12.43+deb12-rt-amd64-unsigned linux-image-6.12.43+deb12-cloud-amd64-dbg [07:30 22] xoa:~$ apt install linux-image-6.12.43+deb12-amd64 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-image-6.12.43+deb12-amd64 : PreDepends: linux-base (>= 4.12~) but 4.9 is to be installed E: Unable to correct problems, you have held broken packages.

@Danp the issue is "resolved" only because we got the host back online so it released the lock. Yes I did try Start on which is method that produced the "The VDI is not available" error no the offline host was not the pool master Yes the VDI's are on shared iSCSI storage (truenas) And I want to note that OTHER VM's that were not on that failed host were able to restart and on any other node without an issue. I was even able to delete old snapshots without an issue so clearly the storage was online and available. It is deeply concerning that we were unable to get the VMs running again and only coincidental that were were able to re-seat the ram module and get it back online -- once it rejoined the pool the locked VM started without any issues on another host, so something was clearly locking it down even though it was fully stopped and visible.

Then reboot than broken host and in the meantime, re-issue the power reset command from the master.

I had a similar issue, and what helped me was routing update traffic through Static Residential Proxies to avoid deep packet inspection that was blocking some repositories. They worked better than regular proxies in our setup since they look like normal home users, so the network didn’t treat the traffic as suspicious. You might need to whitelist some domains manually though, depending on how strict your proxy rules are.

Try to disconnect/shutdown XO, and see if your Windows VM still restart every 10-15min.

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

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

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

Testing the agent out on Arch Linux (mainly due to the spotty 'support' in the AUR/generally) and it is working fine - better than what I had before (which did not report VM info properly). I've set it up as a systemd service to replace the previous one I had, also working as expected. This would be fun to contribute towards.

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

@mohammadm Could you share information about your configuration. What system do you use on guest VM? What drivers you are using on guest VM? On VM you are using bios or uefi? I am trying to get to the point where VM can detect GPU but I have some problems. Recreating your guest configuration can simplify things.

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

It might record the max static RAM (IDK)

@DustinB Thank you. I understand, it's absolutely a cosmetic request.

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