Building Out XenServer 6.5 with USB Boot and Software RAID 10
-
I wonder if it's possible to put this into a executable script that could just be downloaded, and run.
-
@DustinB3403 said:
I wonder if it's possible to put this into a executable script that could just be downloaded, and run.
Yes it could, that's part of the goal. We want to be able to fully automate this. In the long run you will likely want a prompt that will ask which devices to add to the array and after that it could do everything on its own.
-
What kind of impact does log writing have on the USB? Is that worth a concern at all?
-
It could be a concern, especially if you are producing a ton of logs.
But with the second server, you could point your logs to that server.
So your compute servers don't ever have to deal with a full Dom0 because of logging.
The backup USB is also there in-case it gets burnt out.
-
@DustinB3403 said:
It could be a concern, especially if you are producing a ton of logs.
But with the second server, you could point your logs to that server.
So your compute servers don't ever have to deal with a full Dom0 because of logging.
The backup USB is also there in-case it gets burnt out.
I wonder if there is a way to make most/all of it run in RAM like with VMware?
-
There might be, but why? You want your RAM for your VM's.
Just use the built in redirection to push it to an off-host server or a dedicated folder.
-
@johnhooks said:
What kind of impact does log writing have on the USB? Is that worth a concern at all?
It wears it out, send that to Loggly or ELK.
-
@DustinB3403 said:
There might be, but why? You want your RAM for your VM's.
Just use the built in redirection to push it to an off-host server or a dedicated folder.
I was just thinking, it already takes up 1GB, if you could have it only take up a small amount and store it in RAM, it might be a help.
-
The issue is that logging on XenServer doesn't just stop. So Maintenance is critical.
You don't want to auto-dump your logs, you might have issues that you want to look into to. So keeping them around somewhere is critical.
-
@DustinB3403 said:
The issue is that logging on XenServer doesn't just stop. So Maintenance is critical.
You don't want to auto-dump your logs, you might have issues that you want to look into to. So keeping them around somewhere is critical.
Oh I wasn't saying to stop logging, I just wondered if it was a possibility to run it in RAM. More of just an inquisitive qustion.
-
You CAN run in RAM. But why? If anything happens the logs vanish. And it uses up memory too, but not normally all that much. But will you have it auto-rotate in some way?
-
Completing the Resync process takes a very long time.....
-
It'll do that
-
@scottalanmiller said:
You CAN run in RAM. But why? If anything happens the logs vanish. And it uses up memory too, but not normally all that much. But will you have it auto-rotate in some way?
I was just wondering if it's possible to do it similarly to VMware. It was more of just a question for questions sake. XenServer already takes up a gig of ram so the rest couldn't be that much. And you could send the logs somewhere else like you mentioned. It was more of just a question to see if it was possible.
-
You can always create a ram disk and put anything there that you want.
-
Just did a reboot on my test system, and the RAID Array is unmounted. Meaning we need to add it to fstab.
-
I reboot without a problem, and the mounting of the array is managed properly by xen without the entry in fstab.
-
On the test setup I built using the OP, the array is lost.
Along with everything on it. It's much safer to keep it stored in fstab..
-
Lost the whole array? That's strange that would imply something went really wrong. The entry added in fstab whould only cause the os to automount the array, nothing there should cause the array itself to get wiped.
What is the current status of your array?
mdadm --detail /dev/md0
cat /proc/mdstat -
This is what is in /var/run/sr-mount....
