Hey all,
We are proud of our new setup, full XCPng hosting solution we racked in a datacenter today.
This is the production node, tomorrow i'll post the replica node !
XCPng 8.3, HPE hardware obviously, and we are preparing full automation of clients by API (from switch vlans to firewall public IP, and automatic VM deployment).
This needs a sticker "Vates Inside" 
#vent
Hi,
Smart backups are wonderful to manage smart selection of VMs to be backuped.
When we browse the RESTORE section, would be cool to get the TAGs back visually, and possibility to filter them
I'd like to get "all VMs restorable with this particular TAG" type of filter, hope i'm clear.
Perhaps something to add to XO6 ?
just to #brag
Deploy of worker is okay (one big rocky linux with default settings 6vcpu, 6Gb RAM, 100Gb vdi)
first backup is fine, with decent speed ! (to a xcp hosted S3 minio)
will keep testing
@sluflyer06 and I wish HPE would be added too
is there anywhere where we can check the backlog / work in progress / to be done on XO6 ?
I did stick to version: 1 in my working configuration
Had to rename my "Ethernet 2" nic name to Ethernet2 without the space
You have to put the exact template nic name for this to work.
@MajorP93 throw in multiple garbage collections during snap/desnap of backups on a XOSTOR SR, and these SR scans really get in the way
Could we have a way to know wich backup is part of LTR ?
In veeam B&R, when doing LTR/GFS, there is a letter like W(weekly) M(monthly) Y(yearly)to signal the fact in the UI
That's pure cosmectics indeed, but practical.
@simonp patched tonight, a job who took 3 hours yesterday took only 1 tonight.
so, big improvment !
need to re up concurrency to 2 or 4 on some jobs to see if I can squeeze more time on the backup window
hey,
Could be of some interest for french speakers and why not others in the forums :
https://go.veeam.com/webinar-technical-cloud-club-france
hello there, still XOA 6.3.3 here.
since the last big XObackup & CR reworking, we have an annoying bug
This VM is 2.17Tb
how can be the KEY is 9.1Gb ?
In fact the KEY size is good, but when retention of 10 points is obtained, the merging of last incremental in the first KEY point of the chain erase the size.
So in our restore view, data sizes are all wrong, based on the sum of this key + 9 inc
@florent could you do something about that ?
@poddingue there is a notion of appliance too (group of VMs)
https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands
where you can start/stop a group of VMs, never tried it, doesn't seem to have a boot order in the vAPP neither
if you have other SRs, migrating VDIs/VMs is known to correct the "visual issue"
the bug just populates a metadata of the VDI making XOA Web UI believe it's a snapshot, and it is not...
a dev told us in another thread they are on it, but it will be a two phase remediation I believe, correcting the bug so that it doesn't reproduce and a way to script out this metadata on impacted VDIs
this is only guesses
@AlexD2006 you are right, this is dangerous.
I also have them old & dusty base copies from the seventies 
do not shoot them.
@AlexD2006 this is a current bug, not solved yet
you could try that on one VM : snapshot it, revert to snapshot (VDIs will re appear in the disk tab of the VM), then delete snapshot.
rince & repeat for each VM...
problem of disappearing VDIs could come again.
There is no harm to the VMs, in XO6 you should see the VDIs are there (like in XCPNG Center).
xo-cli calls also work normal.
@AlexD2006 could you check directly in the disks tab of the SR if all VDIs have a snapshot icon on them ?
@vlamincktr XO PROXY from source is pretty reliable at no cost
either use @acebmxer script or @ronivay
here is a quick tuto on an ubuntu VM
https://omnibox.huducloud.com/shared_article/QJ9y1bRSPj9VTbWp6NKaV7yn/installation-xoa-a-partir-des-sources-github-ronivay
first part is XO CE, second part is XO PROXY CE
beware as you delegate some jobs to XO PROXY, to ever upgrade XO PROXY when you upgrade XOA, so that they have the same backup mechanisms/code
one way to double backup performance would be to put a XO PROXY on the host where XOA is not.
you could then dedicate some jobs/vms through this XO PROXY, running at the same time as backups running through XOA.
the hosts would still be in one Pool, but flow of backups would egress simultaneously from XOA and XO PROXY from the two hosts.
Hosts are managed via XOA.
and so is the backup.
while backups are running, monitor your bandwidths, you will see that backup flow through XOA.
So having the two hosts in their own pool will get you no gain in term of backup performance I guess...
You have the advantage of facilitated network configuration with the two hosts in the same pool as network is pushed from pool config. I could see that as a downside when separating the two hosts.