Hi, Remotes and SRs aren't managed the same way by XO. XO is connected directly to the remotes to do some read/write operations, unlike SRs which is connected to them via XCP-ng. So the SRs aren't directly managed by XO, but are managed using the XCP-ngs' XAPI and we are limited to what the XAPI provides as information.

Hi, FreeBSD install was already documented officially: https://xen-orchestra.com/docs/installation.html#freebsd You could have test to use HTTP instead of HTTPS to see if perfs are improved New XO backup code will come in few releases that will speed up things Quiesce snapshot: it's not needed for Linux VMs because of the disk driver automatically handling this.

Hi @olivierlambert , cool. Thank you. That makes clear for me now. Andy

Cancel that! I found the keys icon for sending the combo just above console.....

I've created a PR for this issue, feel free to test this branch: https://github.com/vatesfr/xen-orchestra/pull/5341 julien-f opened this pull request in vatesfr/xen-orchestra closed fix(xo-server/{CR,DR}): add tags at VM creation #5341

https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

You need to select a template first.

Hi @anchen Thanks for the feedback that will be helpful to build the new UI from scratch Pinging @pdonias @badrAZ and @badrAZ about this

@olivierlambert ahh gotcha ok thanks for the info

Yes indeed, in CR, you'll send a copy of the disk toward a destination SR. But still, the snapshot is made on the same storage. However, I get your point, and I think in theory, it could be doable with some heavy changes in the storage stack (to have a snapshot located "elsewhere"). However, for each read in the VHD chain, you'll have to read on multiple storage at once, which can be complicated technically speaking (especially if they are shared)

Will do

@kirovtome > xo-cli --list-commands vdi.set vdi.set id=<string> [name_label=<string>] [name_description=<string>] [size=<integer|string>]

Thanks. It works now.

It seems that Debian Buster has some problems with Kubernetes. While this base setup is working, one should also assure that every tool uses the legacy iptables. If not, pod's will not be able to reach the kubernetes api... And then... failure all over! So we also need: update-alternatives --set iptables /usr/sbin/iptables-legacy update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy update-alternatives --set arptables /usr/sbin/arptables-legacy update-alternatives --set ebtables /usr/sbin/ebtables-legacy ```

Genius! That did the trick. Much appreciated.

Hi, Audit logs aren't in the same location than the xo-server logs. To get Audit logs you can use this command xo-cli audit.getRecords which returns an array of records. xo-cli audit.getRecords This command has an option ndjson, which allows you to export logs in a ndjson format. xo-cli audit.getRecords ndjson="json:true" @=<outputPath>

Hi @olivierlambert , gotcha, no worries. I will just leave it there. Thank you for the reply. Andy

@Rocky most like a connection issue, but since you already restarted I think the logs are already gone. If it was a one-off I wouldn't worry about it (but do make sure that the backup is actually working, may be a good idea to do another full backup).

I was able to find the reason XO is not working with cloud-init. XO attaches iso with the cloud-config data as additional disk xvdb and it does not work. But if you provide it as a cd? It will. That is why - as for now you will need to create your own iso and attach it as a cd-rom. You do that this way: Get your files ready (meta-data network-config user-data). My examples below: metadata: instance-id: local-nocloud local-hostname: myhost.example.com network-config: network: version: 1 config: - type: physical name: eth0 subnets: - type: static address: 10.0.0.5/24 gateway: 10.0.0.254 - type: nameserver address: - 8.8.8.8 - 8.8.4.4 search: - example.com - type: physical name: eth1 subnets: - type: static address: 192.168.0.5/24 user-data: #cloud-config ### RUN CMD runcmd: - /usr/bin/apt -y install mc - /usr/bin/date >> /root/testfile # set system default user system_info: default_user: name: testuser gecos: Default Cloud User # password auth - comment out if not using passwords password: testpassword ssh_pwauth: true chpasswd: { expire: false } # do some package management #package_update: true packages: - iptraf - mtr - screen - net-tools - atop Generate iso genisoimage -output myiso.iso -volid cidata -joliet -rock user-data meta-data network-config Upload iso to XO home -> storage -> iso's -> disks -> new disk Prepare VM/template Install Debian 10.6 with xo-tools install cloud-init and cloud-initramfs-growroot remove all network configuration leave just "allow-hotplug ethxxx" (network config will be added in /etc/network/interfaces/50-cloud-init. It will not overwrite yours) shutdown the machine and create the template if you want or just restart VM. DO NOT LET IT BOOT! - keep it in grub. attach your iso let it run It will do whatever you need on the machine.

This is a great news as I will be able to have all my scripts written as of now and xo-cli in one place. Thanks @olivierlambert For those who are looking for direct instructions ... on Debian 10.x: # install npm: apt install npm # install xo-cli: npm install -g xo-cli