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

@olivierlambert said in Detached Backups: You can do that already if you like (combined rolling snap and delta backup). But what's the point? Oh, wow. You can combine backup methods in the same job (as long as they are compatible methods (i.e. Delta and CR). This is cool. I currently have separate jobs for my deltas and CRs. I'll need to make time to make the changes, but this will simply things greatly. I'll even throw in a few extra snapshots to retain. So, yea, this is pretty much what I was thinking of. I didn't realize it was there. Why would I need this? Well, when my WSUS installed the Xen drivers on all my Windows VMs, I went a day before realizing what happened. A snapshot would have been sufficient, if I had one from the day before. Instead, I restored the backup which broke the chain. @olivierlambert said in Detached Backups: edit: about your previous question, restoring without breaking the chain. That might be possible. In theory, after restore, we should take a snapshot before booting the backup and then re-link the restored VM to the backup folders. It's doable (renaming some folders correctly) but I'm not sure this will be very useful. I'll look into this when I get some time. Thanks.

@spidernin If you go to Backup > Restore, it will show you the number of existing backups for each VM.

OK thanks for your answer. we'll look into that. Best regards.

Yep

We decided to keep cloudinit available for everyone for now. So consider it as a gift

Hi, If you want to change the background color, you need to update the $side-menu-bg: #044b7f; in ~/xen-orchestra/packages/xo-web/src/index.scss . Best regards.

It's exactly the same process for any other backup.

@stormi so now I have to just figure out how to delete the ghost vm before i reconnect the pool to XO. in xen center I can't delete it for some reason .. guess i'll try cli (never deleted a vm like that before)

That's precisely the difference: a delta backup is stored in a remote, a CR is stored in an SR.

Thanks for the ticket. Please continue to provide feedback in there, it won't be monitored here.

@Rocky said in Backup File resotre errors: ntfs-3g Yes I have both those packages installed