@dknight-bg the Feeder post you linked asks for two things: sending audit events to syslog, which is what this PR does, and recording successful logins, which as far as I can tell the PR doesn't touch. If others reading this need either one, a vote on https://feedback.vates.tech/posts/88/audit-log-forward-events-to-remote-syslog-record-successful-logins is the easiest way to show it. The PR is still waiting for a reviewer, as far as I can see.

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.

@mpiton Thanks for looking into this, I guess it wasn't apparent that I needed to click the Save Configuration button for that plugin. I did that and confirmed that the secret now survives an xo-server restart. Thanks again!

Hello, You can find all the demo dashboards at the following address: https://github.com/steeve-san/OpenMetrics_XCP_Grafana Regard,

@florent Thanks for your reply! We have started to migrate thousands of VMs, so disk transfer speed is important for us.. We will also do our detailed tests soon with different threads setting and publish it here. I think threads=1 is a good and logical default, but not efficient. Others might complain if you set it to a higher value. Configuration option would be a real good solution.

@gcpeters4 said: @john.c This is a good idea as well. If the previous suggestion of trying to do a DNS round robin approach doesn't work, this may be my best option. Thanks for taking the time to provide your suggestion! By the way my suggestion is recommended best practice from Microsoft for their Active Directory software and/or technology. My suggestion will be more likely to work if your DNS servers and requests have issues with Round Robin configuration. Plus with my solution you can easily add more servers as domain controllers to the cluster, as required and use replication to keep them consistent and up to date.

@dlgroep Thank you, we will take thin/thick token into account and use 'claims' part for other properties.

That's a very good question, let me ask internally. Ping @pdonias he might know the answer

@mjr99 I bypassed it weeks ago. Didn't have to downgrade netbox. At the time. I upgraded to the latest Xo from sources. Then netbox worked. I shall be upgrading xo soon again Thank you all.

Ok, my syntax is oudated. resize_rootfs: true growpart: mode: auto devices: ['/dev/xvda3'] ignore_growroot_disabled: false runcmd: - pvresize /dev/xvda3 - lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv || true this one works. final_message. doesn't support any macro like %(uptime) %(UPTIME)

@bleader Hopefully the palm print on my forehead isn't visible from where you are sitting. Of course the interface needs an IP address. In my defense, normally for something like this, I wouldn't put it on the bonded interface with all the trunked VLAN's for guest traffic (we don't give that one an IP) and it would go on the other bonded interface that isn't trunked and does get an IP, but these are test hosts and I didn't set up the other bond, so it is pulling double duty. I was able to set the IP's and get SDN working. Thanks!

Indeed, and it's clearly stated at https://docs.xen-orchestra.com/community

Adding @pdonias in the loop

Once again, thanks for all the work you’ve done. If it hadn’t been for last night’s AI hallucination, I wouldn’t have dug in so deeply — and I ended up learning a lot. All the best!

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

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]

@Berrick Ah cool, I was anticipating that doing it live would've caused boot issues but I think I've just got a bug in my head about how it actually works, I'm conflating two separate things based on an incorrect interpretation of a previous experience I had once with XCP. Thanks!

That's weird, but OK. Maybe it's because even when you update, the old/existing RRDs data won't be "replaced".

@DustinB Guest tools simply don't support the system I'm running.