Xen Orchestra on Ubuntu 15.10 - Complete installation instructions
-
@scottalanmiller said:
@DustinB3403 said:
@Danp said:
@DustinB3403 said:
But you may not want to use NFS on your XO server. . . .
Maybe you use it just to manage the VM's but no do backups.... so um, no.
True. However, this creates a situation where the software claims to support NFS remote shares, but it doesn't work properly without this package.
NFS shares are likely to be faded out in favor of SMB Lib's that only get used at the time of backup or restore.
Ubuntu Minimal is the installation media chosen, I would also assume Ubuntu Full DVD would work as well, but it would be bloated in comparison. If a note isn't sufficient I don't see how forcibly installing NFS-Common is going to fix the issue in the first place.
Forcing NFS-Common onto your system would somehow defeat the purpose of using the minimal installation media
Except the point of a script is to run it, not to read it. if people wanted to read it, they wouldn't run a script to do the work.
Well they don't have to read the script, but the how-to would be wise...
@JaredBusch said:
@DustinB3403 said:
Forcing NFS-Common onto your system would somehow defeat the purpose of using the minimal installation media
How in the hell did you reach that conclusion? Installing a single extra package comes no where close to "defeating the purpose" of a minimal install.
On the other hand by adding a commonly used file sharing system you negate problems with people attempting to actually follow the instructions and get something working.
Again, it's why Read-Me's exist.... so that the "user" knows what the hell is going on. the read me is literally a few lines.
But I digress.
-
Script updated to perform NFS-Common installation at the start, and then everything else afterwards.
Read-Me updated.
-
@DustinB3403 Thanks!
-
Anyone already tackle the issue of how to start XO automatically when the VM is booted? If so, what was your solution?
-
@Danp said:
Anyone already tackle the issue of how to start XO automatically when the VM is booted? If so, what was your solution?
I haven't looked into this yet, but you could run a crontab job at boot that does this for you.
-
@DustinB3403 said:
@Danp said:
Anyone already tackle the issue of how to start XO automatically when the VM is booted? If so, what was your solution?
I haven't looked into this yet, but you could run a crontab job at boot that does this for you.
I always forget that cron can take care of that, rather than writing your own init or systemd script. Probably the best way to handle it quickly and easily.
-
Good old cron....
Always being forgotten about
-
At the moment I'm build a test XO update script..
Wish me luck.
-
So I've made a super simple script file that will update your XO installation.
I recommend that you shutdown the XO services while this runs.
sudo mkdir /opt/xo-update cd /opt/xo-update wget https://gist.githubusercontent.com/Jarli01/4d32d4f1b8c5786c9299/raw/c1af91129bdbd4775653932aa957c2ea48889fe7/xo-update.sh chmod +x xo-update.sh
To run it
from /opt/xo-update
sudo ./xo-update.sh
-
@DustinB3403 can we just add this as an option to @scottalanmiller script? Having it all in one script would be nice.
-
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? -
@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?A bit Windowsee
-
@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 stop
But 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 stop
But 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.