BRRABill's Field Report With XenServer

scottalanmiller

@scottalanmiller said:

If I told you that you needed to stop using GUIs and only work from the command line, then no, the RSAT would not meet that requirement. But that was not the context of the discussion. This was purely around how the servers get managed.

My question was in relation you you saying things like Linux admins would laugh at you if you needed a GUI. So, in reference to THAT, I think using RSAT is still a GUI. And hence would get you laughed at.

Oh okay, yes, if you need the RSAT Linux Admins would laugh at you. I don't know many people who are Windows Admins are rely on the RSAT. They might use it, but they don't rely on it. If you remove the local GUI on Windows, pretty universally you learn PowerShell plus RSAT, not RSAT alone.

BRRABill

@olivier said:

@BRRABill autoboot issue fixed: https://github.com/vatesfr/xo-web/issues/879

Will be released in 4.16. Thanks for the report!

I'm glad I could help.

I like to go over every little thing when I am learning something new.

Hence why it seems like I am asking a lot of dumb questions.

Well, in truth a lot of them are just dumb.

scottalanmiller

Same on Linux, there are RSAT-like tools, like Landscape. They are acceptable to use, but if you need them, no one will think you are an actual Linux Admin.

BRRABill

Back to XenServer.

Decided to try an update tonight. Two "errors" popped up, and I was wondering what the mechanics were behind these error messages.

I included screen shots below to support the questions, but here they are...

Why does autostart need to be disabled? (I am assuming it is because of #2.)
Why is it migrating the VM somewhere? What exactly is it doing? How does this work with just one XenServer?

Dashrender

probably in case there is a startup problem. You're updating the hypervisor, if all goes well, you can re-enable autostart, at least this way, they won't be in the way if there are problems with the hypervisor update.
2)I'm not sure why it assumes you have a second or more server to migrate to, but appears to be trying to do you a solid by moving your vms to another host.

Mine did this too.

scottalanmiller

I think this is because you are trying to update while VMs are running and if it does that, they are going to go down and if they are not set to autostart they are not going to come back up at all. XenServer doesn't want to induce an unexpected outage.

BRRABill

Yeah I am wondering why it would assume
a) I wanted to migrate and
b) I had another server to migrate to

DustinB3403

If you have the autostart flag set on your VM's it makes that assumption that you're attempting a Failover system where the VM's can get migrated to another host.

Autostart was actually removed from XC as a default option, it must be enabled via the CLI.

Disable Autostart on these VM's and try again.

Dashrender

@DustinB3403 said:

If you have the autostart flag set on your VM's it makes that assumption that you're attempting a Failover system where the VM's can get migrated to another host.

Damn awesome answer! much better than my - If you're kicking off a hypervisor upgrade while a VM is running, wouldn't you assume you want it migrated?

Dashrender

@BRRABill said:

Yeah I am wondering why it would assume
a) I wanted to migrate and

See my previous reply

b) I had another server to migrate to

It's ok to assume this - it wasn't a hard failure. If you had one, it would migrate, if not, it would log it and move on.

DustinB3403

You would, but the autostart flag is for after a power outage etc, not a migration, as the VM never gets "powered off"

Upgrading the host, attempts to migrate the VM to any other host in the pool, as its assuming you want to keep it running, since the Autostart flag is enabled.

Otherwise it'll say "you need to shutdown these VM's"

BRRABill

@DustinB3403

And it always has to shut down the VMs when it does an upgrade?

I know Windows requires a lot of reboots, but they generally run the updates while everything is running.

This is more informational knowledge. I could have just suspended the VMs as it asked. Just curious as to how the sausage is made. (Boy I am full of cliches today.)

BRRABill

@DustinB3403

I guess I don't understand the mechanics of upgrading here. I mean, you suspend the VM, take the 60 seconds to upgrade, and then restart it.

To migrate some VMs would take hours. Is that more in the scenario (of which I am not in even remotely) of VMs that can never be down?

DustinB3403

@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.

DustinB3403

@BRRABill said:

@DustinB3403

I guess I don't understand the mechanics of upgrading here. I mean, you suspend the VM, take the 60 seconds to upgrade, and then restart it.

To migrate some VMs would take hours. Is that more in the scenario (of which I am not in even remotely) of VMs that can never be down?

The mechanic is looking at what you have and trying to make a determination of what you are attempting to do. aka HA. Which if you don't have, you need to power off the VM's and disable autostart so the installation can complete.

BRRABill

@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?

Romo

@BRRABill I believe the job is failing because a vm that has autostart set on can't failover to another host. If it did and the original host once it rebooted will try to "autostart" all the vms again causing you to have the same vm active in 2 different hosts.

scottalanmiller

@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

BRRABill

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.

scottalanmiller

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.