XO Backups and location of XO VM
Newbie question. If I set up backups in XO, does the XO VM have to be on the same network as the VMs that the backup jobs are set up for and does it have to remain running continuously in order for backup schedules to execute? In other words, if I have XO on my management laptop offsite and I connect up with a VPN and set up backup jobs, what happens when I disconnect my management laptop from the VPN? Will those backup jobs not run since XO isn't on the same network (and may not be running)?
XO (in fact, its server part, not the browser client) is meant to run 24/7, as a service/daemon.
As long as XO is the same network of your pool, it's fine. If you access XO behind a NAT, it's not a problem. But
xo-serverMUST be in the host network.
Thank you. That makes perfect sense and is what I suspected.
@RKENS One other newbie question. I noticed when I set up a continuous replication job, the target VM was set to auto start. I had to manually change that to not auto start since it is a CR target and can't be allowed to start. I assume that is normally since the source VM was set to auto start and I assume it is normally that I should go to each target VM after the initial VM and shut off auto start, is that right? Also, will it retain my change forever after that as long as that backup job exists?
This is a question for @julien-f
It seams that after every continuous replication backup job, the VM on the destination storage is set to auto start, even if I have previously turn that off manually. I'm thinking that is a problem since a reboot of the destination host server will cause all those backup VMs to try to auto start. Theoretically, they won't be able to start since they are disabled from the CR job, but that doesn't seem right. I'm wondering if a setting or programming change needs to be changed to turn off auto start on CR backup jobs.
@RKENS Good question, during the replication, a new VM is created with the same settings as the original one, and this at every run. Therefore that's perfectly normal that this property reappears.
I don't see how that's a problem because, as you said it yourself, the start operation is disabled by the replication job.
I think it makes sense that the auto start is set like on the original VM so you can simply start the replication when necessary without having to think about enabling it.