BRRABill's Field Report With XenServer
-
@BRRABill said:
@DustinB3403 said:
@BRRABill Xen would simply put the VM's in a suspended state, unless there is a known need to reboot the host. In which case it tells you, hey move these VM's or shut them down.
Got it.
And I am assuming XS works like other hypervisors on suspend? Conceptually at least?
Yes
-
I was discussing a bit offline with @DustinB3403 about switching my XS install over to boot off of USB.
I know it is the ML recommendation, but as always, I am questioning the thinking.
Perhaps it is just my scenario, but I'm not understanding the advantage of doing it.
In a server where all the data is stored on one array, what is the disadvantage of booting off this array as well? I understand that if the array goes down you could continue to boot off the USB, but if the array goes down, you have bigger issues to deal with anyway. As @scottalanmiller always says XS is very easy to install. Set up the new array, install XS, and restore your VMs.
How does booting it off USB save any work in restoring the VMs? Maybe the 5 minutes it takes to install XS.
Now, if you are hosting hundreds of VMs and have to set them all back up, I could see. But it still would seem to be a substantial task if that array were to go down.
I understand there is a small storage hit, but XS is so small, I don't see the advantage there, either.
So, as another thread this week said, I'm not accepting, but questioning.
-
Simple answer is... if your array fails you want as much power as possible to repair it. If your XS install is on the failed array, you have a lot more work to do at a time when that's the last thing that you want. Losing your array AND the tools necessary to recover the array all at once really, really sucks. Considering that the fix is incredibly trivial, why give up so much power?
Also, if you need to roll back a failed patch or upgrade to XS and you are installed to the local storage, how do you do it? This is trivial with USB/SD storage.
-
@BRRABill As discussed offline, and @scottalanmiller mentioned it.
If you lose the array, which is also hosting the Hypervisor installation your ability to recovery in a timely manner is greatly decreased. The array is down, which host the XS, so how do you repair it?
Included is your VM's are down and unusable unless you can migrate them.
By putting the XS installation on USB/SD card you're not risking the array and options to roll back a system update or dead USB/SD card.
Let the array act as block storage, not as the boot device.
-
@scottalanmiller said
Simple answer is... if your array fails you want as much power as possible to repair it. If your XS install is on the failed array, you have a lot more work to do at a time when that's the last thing that you want. Losing your array AND the tools necessary to recover the array all at once really, really sucks. Considering that the fix is incredibly trivial, why give up so much power?
But how is it a lot more work? You've said many times XS is a breeze to install. Fix the array (which probably means recreating it from scratch if the drives have failed), reinstall XS, restore the VMs. I don't see how the USB saves you time here.
And what tools do you mean? Unless you are talking software RAID, which I was not considering in my argument, but is a valid point.
Unless this whole thing is in the discussion of software problems on the array. That is something I was not thinking about. That you could inadvertently hose your array without the hardware component of it ever failing.
Is that what you mean?
-
@BRRABill XS is super simple to install, but if your XS installation is fried (and built on the array) you have to reinstall XS and import from your backups.
But if you fry a USB drive, you just shutdown the host, and plug in your cloned XS Bootable USB.
The VM's are intact, and you recovered in the time to shutdown the server and connect a working USB (that has your customizations already configured, SR configured, hardware and everything)
-
@BRRABill said in BRRABill's Field Report With XenServer:
@scottalanmiller said
But how is it a lot more work? You've said many times XS is a breeze to install. Fix the array (which probably means recreating it from scratch if the drives have failed), reinstall XS, restore the VMs. I don't see how the USB saves you time here.
That XS is easy to install isn't the issue, that's beside the point. It's dealing with the array, which is not easy to recreate, that is the issue.
Installing XS after a failure is silly, have it ready to go before a failure.
Restoring an array when you've lost the array controller is a big deal, I can't understand why you'd even consider opting to have this in your process. This could easily be what kills you and causes data loss. It's time consuming, complex and a lot of risk. For what purpose?
Basically, you are looking at going against the advice of every hypervisor vendor and the industry which are recommend for a reason and doing something only nominal advantageous (saving what, $10?) but... why? You are trying to downplay the advantages, but you are failing to explain why "just a little worse" isn't still "worse."
-
Do a Pros and Cons list. Pros to using SD / USB are solid. Maybe not epic, but they are there. Cons are... what? What factors are driving you to want to question a nearly universal industry standard from both the IT and the vendor sides?
Not that questioning is not good, but industry accepted best practices normally exist for extremely strong reasons. Reinvesting the wheel or approaching things from a "I must be a special case" are basically always wrong.
-
@scottalanmiller said
Basically, you are looking at going against the advice of every hypervisor vendor and the industry which are recommend for a reason and doing something only nominal advantageous (saving what, $10?) but... why? You are trying to downplay the advantages, but you are failing to explain why "just a little worse" isn't still "worse."
Hey I am questioning everything!
I'm in agreement it is the right way to do it. I just don't understand why the other way is so bad. This is purely educational at this point.
Other than if the XS installation gets hosed. Unless some update goes bad, what could kill XS on the array?
-
@scottalanmiller said
Not that questioning is not good, but industry accepted best practices normally exist for extremely strong reasons. Reinvesting the wheel or approaching things from a "I must be a special case" are basically always wrong.
Purely educational.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@scottalanmiller said
Basically, you are looking at going against the advice of every hypervisor vendor and the industry which are recommend for a reason and doing something only nominal advantageous (saving what, $10?) but... why? You are trying to downplay the advantages, but you are failing to explain why "just a little worse" isn't still "worse."
Hey I am questioning everything!
I'm in agreement it is the right way to do it. I just don't understand why the other way is so bad. This is purely educational at this point.
Other than if the XS installation gets hosed. Unless some update goes bad, what could kill XS on the array?
The array controller dies... too many disks die...
-
@dafyre said
The array controller dies... too many disks die...
Right but if that happens (or you lose more than 1 disk which has happened to me) your data is all gone anyway, right? ANd you are restoring the VMs from backup anyway.
-
@BRRABill said in BRRABill's Field Report With XenServer:
I'm in agreement it is the right way to do it. I just don't understand why the other way is so bad. This is purely educational at this point.
Mistake: You changed "not as good" to "so bad". That's confusing you.
-
@scottalanmiller said
Mistake: You changed "not as good" to "so bad". That's confusing you.
You know, that is a great way of looking at it.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@dafyre said
The array controller dies... too many disks die...
Right but if that happens (or you lose more than 1 disk which has happened to me) your data is all gone anyway, right? ANd you are restoring the VMs from backup anyway.
So in SOME cases, it's not AS advantageous, but still advantageous, right? You are saying that while it is better, it's not enough better to justify not doing something worse? That makes no sense.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@scottalanmiller said
Mistake: You changed "not as good" to "so bad". That's confusing you.
You know, that is a great way of looking at it.
I've gotten used to that problem with RAID 5. Someone will argue with me that RAID 5 isn't "that bad" and they'll forget that they are only trying to minimize the worse, not show why it's okay.
Because only the "best" option should ever be considered.
In the case of local boot, unless we have a reason that it is "better", then it is "worse", so avoid it.
-
And to be clear, there is no reinstall of XS on an existing drive, right?
It trashes whatever you install it on?
-
@BRRABill said in BRRABill's Field Report With XenServer:
And to be clear, there is no reinstall of XS on an existing drive, right?
It trashes whatever you install it on?
Right. Thankfully, it is really easy to make an exact copy of the XenServer drive. Hrm, I actually need to do that tody. I'll try to take screenshots and do a how-to type writup.
-
-
@DustinB3403 said in BRRABill's Field Report With XenServer:
See here
http://mangolassi.it/topic/8537/how-to-clone-a-xen-usb-on-windows
Well, that's one less thing for me to document here
Then again, I'm going to be doing this on a live, running XenServer (LVM is great, you should sing it's praises.)
