Xen Orchestra on Ubuntu 15.10 - Complete installation instructions
-
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@Dashrender do you mean run XO from Xen directly?
Rather than in it's own VM?
No, run the scripts that update XO, and kick off the backup/snap/etc of XO from XC/Xen directly.
But why?
You can run a scheduled backup from within XO to backup your XO VM on any schedule you set. Once that completes run the xo-update.sh script and confirm all is functional.
This would also allow you to take advantage of the Continuous delta capabilities. Rather than having to build a full every time you want to update.
It would be much easier to set a backup to run weekly for just the XO VM, stop the services, run the update, reboot XO VM, and restart the services.
The problem on relying on the delta from within XO is what if the update breaks XO? How do you now roll the delta back?
-
@Dashrender said:
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@Dashrender do you mean run XO from Xen directly?
Rather than in it's own VM?
No, run the scripts that update XO, and kick off the backup/snap/etc of XO from XC/Xen directly.
But why?
You can run a scheduled backup from within XO to backup your XO VM on any schedule you set. Once that completes run the xo-update.sh script and confirm all is functional.
This would also allow you to take advantage of the Continuous delta capabilities. Rather than having to build a full every time you want to update.
It would be much easier to set a backup to run weekly for just the XO VM, stop the services, run the update, reboot XO VM, and restart the services.
The problem on relying on the delta from within XO is what if the update breaks XO? How do you now roll the delta back?
You don't backup to the XO vDisk you backup to a separate NFS target
-
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@Dashrender do you mean run XO from Xen directly?
Rather than in it's own VM?
No, run the scripts that update XO, and kick off the backup/snap/etc of XO from XC/Xen directly.
But why?
You can run a scheduled backup from within XO to backup your XO VM on any schedule you set. Once that completes run the xo-update.sh script and confirm all is functional.
This would also allow you to take advantage of the Continuous delta capabilities. Rather than having to build a full every time you want to update.
It would be much easier to set a backup to run weekly for just the XO VM, stop the services, run the update, reboot XO VM, and restart the services.
The problem on relying on the delta from within XO is what if the update breaks XO? How do you now roll the delta back?
You don't backup to the XO vDisk you backup to a separate NFS target
Sure, but what does the restoration? it's XO, right? So if XO is broken you can't run the store, right?
-
You can export from the NFS Share using WinSCP and import directly into XenCenter if things are horribly broken.
-
@DustinB3403 said:
Already tried it.
Doesn't appear to work.
Post your cron entry here.
Also may want to review these options:
https://www.npmjs.com/package/node-crontab
https://www.npmjs.com/package/forever -
Ok So here is what I've done to get XO to run at boot.
I made a script in /etc/ named "xo-start.sh" marked it as executable.
cd /etc nano xo-start.sh #!/bin/sh cd /opt/xo-server sudo npm start ctrl+o ctrl+x sudo nano /etc/crontab # shit ton of comments # @reboot cd /etc && ./xo-start.sh ctrl+o ctrl+x sudo reboot now -
That should be all you need to get XO to run at startup of your XO VM.
I've reboot several times to confirm.
-
So the last question is, how do we get XO to stop so we can manually run our updates.
-
If you are firing up from cron, which is pretty normal for a low key service such as this, then you would kill it using the kill command.
-
Problem is, with processes that run via npm or similar, their name never appears and there is no universal standard for stopping them. Doing so manually is super simple, but in a script is dangerous and ill advised. If you are very brave you can use ps and look for npm, but if the server is running anything else, you might kill the wrong thing.
-
And to complicate things, there is no stop script for xo-server
-
@scottalanmiller said:
Problem is, with processes that run via npm or similar, their name never appears and there is no universal standard for stopping them. Doing so manually is super simple, but in a script is dangerous and ill advised. If you are very brave you can use ps and look for npm, but if the server is running anything else, you might kill the wrong thing.
Doesn't 'cd /install/location' 'npm stop' work? Why make it difficult?
-
@travisdh1 said:
@scottalanmiller said:
Problem is, with processes that run via npm or similar, their name never appears and there is no universal standard for stopping them. Doing so manually is super simple, but in a script is dangerous and ill advised. If you are very brave you can use ps and look for npm, but if the server is running anything else, you might kill the wrong thing.
Doesn't 'cd /install/location' 'npm stop' work? Why make it difficult?
No, there is no stop script.
-
@travisdh1 said:
@scottalanmiller said:
Problem is, with processes that run via npm or similar, their name never appears and there is no universal standard for stopping them. Doing so manually is super simple, but in a script is dangerous and ill advised. If you are very brave you can use ps and look for npm, but if the server is running anything else, you might kill the wrong thing.
Doesn't 'cd /install/location' 'npm stop' work? Why make it difficult?
from my testing npm stop does not work.
It's not even included as a script.
We would have to effectively Ctrl + C out of the crontab job.
-
This will stop it, if you run it as expected and nothing else is running like it:
kill $(ps aux | grep "npm start" | grep -v grep | cut -d' ' -f8) -
@scottalanmiller said:
@travisdh1 said:
@scottalanmiller said:
Problem is, with processes that run via npm or similar, their name never appears and there is no universal standard for stopping them. Doing so manually is super simple, but in a script is dangerous and ill advised. If you are very brave you can use ps and look for npm, but if the server is running anything else, you might kill the wrong thing.
Doesn't 'cd /install/location' 'npm stop' work? Why make it difficult?
No, there is no stop script.
Well, bother.
-
@DustinB3403 said:
We would have to effectively Ctrl + C out of the crontab job.
Ctrl-C doesn't do what you think that it does.
What we need to do is to send a SIGHUP to the process, which is what I did. It's identifying the process that is the issue.
-
@scottalanmiller said:
This will stop it, if you run it as expected and nothing else is running like it:
kill $(ps aux | grep "npm start" | grep -v grep | cut -d' ' -f8)Will test in a moment.
Have to complete another job real fast.
-
Where the problem lies is that npm does not appear to store the PID anywhere on its own. Could we had that manually to the cron job? Of course, but that would not be universal by any stretch and we'd be left with a script that only worked with that specific means of starting.
-
kill $(ps aux | grep "npm start" | grep -v grep | cut -d' ' -f8)Doesn't work.
