Xen Orchestra on Ubuntu 15.10 - Complete installation instructions
-
@anonymous said:
@DustinB3403 can we just add this as an option to @scottalanmiller script? Having it all in one script would be nice.
The installation script only currently does the installation.
Where as updating could be performed daily or even weekly depending on how often @olivier and his team make adjustments.
Having the separate script made more sense to me.
-
Now you could, just rerun the installation script.... but that seems like overkill.
-
@Dashrender said:
Should you perhaps add the shut down of XO to the script? Perhaps prompt the user that it's going to happen and give them an out?
Or is that to Windowsee?That is a very simple exit command.
But presumably you want to run it on your schedule. So it's not getting turned off at whatever schedule.
sudo npm stopBut yeah....
-
@DustinB3403 said:
Now you could, just rerun the installation script.... but that seems like overkill.
Agreed.
-
@DustinB3403 said:
@Dashrender said:
Should you perhaps add the shut down of XO to the script? Perhaps prompt the user that it's going to happen and give them an out?
Or is that to Windowsee?That is a very simple exit command.
But presumably you want to run it on your schedule. So it's not getting turned off at whatever schedule.
sudo npm stopBut yeah....
ummm.. wouldn't you be running the update on that same schedule? I'm assuming there would be some kind of service interruption when you apply the updates? at least a possible one.
-
@Dashrender The only interruption would be to XO, not your VM's.
If you have "maintenance planned" then you run your updates and go on with your day.
My reasoning for making it a manual run, is if you break your installation, then its on you. You can't access the files while XO is running, it breaks something in there (from experience)
Since this is the Open-Source version, I'm assuming you'll (we) will only update when we see something is broken, or a need for a feature, or lastly because it's awesome and we need to update.
Shutting down the system automatically could be detrimental to your infrastructure (breaking your XO installation) which can effect your backup schedule.
IE new XO installation, would change your backup schedule.
Edit: meaning your backup directly might inadvertently become full because you end up with delta's and the initial full which never go away.... -
Does XO have "HA" capabilities? Can you run two XO servers in sync?
-
@coliver said:
Does XO have "HA" capabilities? Can you run two XO servers in sync?
Calling @olivier
I'm not sure, I don't see why you couldn't have multiple XO servers running at once, but I'm uncertain of what capabilities you'd gain if any.
Other than the ability to test updates on one host first, and then the other. Limiting your downtime.
-
@DustinB3403
In that case I guess I'd update the script to not only shut down XO before updating, but also running a backup using that other (I can't recall the name of it) backup solution you were using before XO. Then you'd have a fall back point before you ran the update, and could easily fail back to it in case you have problems after the updates.now you have a whole solution.
-
@Dashrender NAUBackup, yes it's a viable solution that works from XenServer.
It could certainly work, but it's at a separate host, not sure how you'd script that....
NAUBackup just runs from crontab (or manually if you run it).
I'd just use XC to snapshot what's there for XO, update and test. If all is good, delete the Snapshot.
-
XO is able to back it's self up so that works as well.
-
@DustinB3403 said:
@Dashrender NAUBackup, yes it's a viable solution that works from XenServer.
It could certainly work, but it's at a separate host, not sure how you'd script that....
NAUBackup just runs from crontab (or manually if you run it).
I'd just use XC to snapshot what's there for XO, update and test. If all is good, delete the Snapshot.
There has to be a way to script that. Make it all part of your XO update script.
-
@coliver said:
Does XO have "HA" capabilities? Can you run two XO servers in sync?
Sure, just RSYNC them between hosts. It's a web app, so you can do it in any way that you do with web apps. You can run multiple in parallel for load balancing or whatever. Think of the Xen machines themselves as the databases and XO as the application.
-
@Dashrender said:
@DustinB3403 said:
@Dashrender NAUBackup, yes it's a viable solution that works from XenServer.
It could certainly work, but it's at a separate host, not sure how you'd script that....
NAUBackup just runs from crontab (or manually if you run it).
I'd just use XC to snapshot what's there for XO, update and test. If all is good, delete the Snapshot.
There has to be a way to script that. Make it all part of your XO update script.
Not that I'm not interested. But how?
NAUBackup literally runs on Xen, no VM.
XO runs in a VM.
If you could make outward calls from a VM to the Hypervisor you'd be risking the security of the system as a whole.
-
@DustinB3403 said:
Not that I'm not interested. But how?
NAUBackup literally runs on Xen, no VM.
XO runs in a VM.
If you could make outward calls from a VM to the Hypervisor you'd be risking the security of the system as a whole.
How would you call NAUBackup normally?
-
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@Dashrender NAUBackup, yes it's a viable solution that works from XenServer.
It could certainly work, but it's at a separate host, not sure how you'd script that....
NAUBackup just runs from crontab (or manually if you run it).
I'd just use XC to snapshot what's there for XO, update and test. If all is good, delete the Snapshot.
There has to be a way to script that. Make it all part of your XO update script.
Not that I'm not interested. But how?
NAUBackup literally runs on Xen, no VM.
XO runs in a VM.
If you could make outward calls from a VM to the Hypervisor you'd be risking the security of the system as a whole.
I definitely understand where you are going with that, but I'm assuming that you could create dedicated accounts for these types of tasks, and those accounts would be able to accomplish these goals through remote triggers.
You can update whole server farms remotely in a secure fashion, no reason you can't do these processes the same.
-
Directly from the Hypervisor's crontab job
Or the cli to do it directly.
-
@DustinB3403 said:
Directly from the Hypervisor's crontab job
Or the cli to do it directly.
You can get to the CLI from the VM the same as from wherever you are getting to it from.
-
@scottalanmiller said:
@DustinB3403 said:
Directly from the Hypervisor's crontab job
Or the cli to do it directly.
You can get to the CLI from the VM the same as from wherever you are getting to it from.
Putty and XC.
-
@DustinB3403 said:
@scottalanmiller said:
@DustinB3403 said:
Directly from the Hypervisor's crontab job
Or the cli to do it directly.
You can get to the CLI from the VM the same as from wherever you are getting to it from.
Putty and XC.
So SSH.
The script can use SSH just like Putty can.