BRRABill's Field Report With XenServer
-
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
-
@JaredBusch said:
@BRRABill said:
Do you consider using RSAT going GUI-less?
Is there a GUI on the server or not? If not, then it is GUI-less.
How you choose to manage said server is a different question.
Getting me started on "The Bad Old Days" must you? The first UNIX environment I was an admin in was way back right after Y2K. IRIX had an X11 gui server installed by default, weather a monitor was connected or not. The server just had an old terminal connected to a serial port. Didn't slow anyone down in running the different engineering design applications from running them on the server remotely.
-
@BRRABill said:
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
RSAT is a GUI yes. But the Windows Server you are connected to may not have a gui.
-
@FATeknollogee said:
@FATeknollogee said:
@Dashrender said:
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@FATeknollogee said:
Not to side track this thread (apologies to @BRRABill ), what is the "hyperconverged" equivalent in the XenServer world?
To all you XS experts, what is the "hyperconverged" equivalent in the XenServer world?
Similar to Starwind in the Windows world
XenServer is natively that in the Xen world. Nothing additional needed.
If you had 2, 3 or more XS bare metal installs with local drives, how do you "hyperconverge" all the local disks?
Are you saying with XS the "hyperconvergence" just auto-magically happens?
Of course not, but it doesn't for any platform. If you're setting up a greenfield situation, then you design it from the ground up with XS with single shared storage.
Let's try this again:
In Windows, you can take multiple boxes, add Starwind or Datacore = hyperconverged using local storage (no SAN needed).
How do you do the same thing with XS?
This can do HC for XenServer:
http://www.atlantiscomputing.com/products/atlantis-usxIt's interesting how much of Xen did they sell.
-
@BRRABill said:
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
It's a GUI on top of a non-GUI interface. It is an API. The server doesn't have a GUI itself, you are talking to a text or binary interface (the Windows API, pretty sure it is binary.)
Just like you could build a GUI for Linux that connects over SSH and uses normal commands under the hood. Yes, YOU might be looking at a GUI, but the servers themselves don't have GUIs.
RSAT as a GUI is different in some important ways:
- It is one to many. One RSAT interface for all of your servers, all of your Windows servers at least. No different than how ELK is a GUI for all of your logs.
- It is light. The server(s) only do a light API, all of the graphical processing is on a client machine where load does not matter, and you don't create overhead or exposure on the servers.
- When not in use, it goes away. It does not use resources when things are not in use. Turn it off, it shuts down.
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
These work for Windows, too.
I just found this out. So that helps a lot too.
Like i said -- I'm all for GUI-less servers (regardless of the OS)... but the sys admins for those servers have to be (or get) comfy running the system from RSAT or Powershell.
Indeed, they sure had better. I had someone in a Facebook thread in response to my BASH and SSH on Windows post say that my post was wrong because.... "anyone that doesn't live in PowerShell cannot be considered a Windows Admin and is only a hobbyist." Not the exact quote, but really close. I was told that my article was uninformed and that I didn't know anything about Windows because I accepted people who use anything other than PowerShell as IT pros rather than hobbyists. Me!! @JaredBusch will tell you, no one is more brutal on people using the "wrong" tools or doing things in a non-best practices way or condescending (I like to call it... pushing people to be better) than I am. And yet, even in an article pointing out how important CLI is on Windows, I get flak for giving Windows people way too much credit and that everyone is just a hobbyist.
Which, to be fair, in the Linux world if you said you needed a GUI everyone would laugh at you and no one would let you claim to be a Linux Admin without knowing the command line. If you went into an interview and said you had been one and didn't know the CLI they'd say you lied on you resume and kick you out.
So he was just holding Windows Admins to the same standard. The issue is that it is an absolute standard rather than a relative one. The Windows world has a different culture and using the GUI, for better or for worse, is broadly accepted. It is what it is.
-
@BRRABill said:
Do you consider using RSAT going GUI-less?
From the standpoint of "is the server running a GUI", yes. RSAT is a viable way to admin Windows boxes. Is it a GUI, yes. So from the perspective of "doing administration via scriptable command lines", no.
-
So in reference to what I had posted that prompted this... which was about whether the server should have a GUI, then yes, using RSAT is absolutely GUIless. The server has no GUI.
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.
Likewise, XO is a GUI for XenServer just as the RSAT is for Windows. But XenServer itself doesn't have a GUI, XenServer has the XAPI API.
-
@KOOLER said:
@FATeknollogee said:
@FATeknollogee said:
@Dashrender said:
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@FATeknollogee said:
Not to side track this thread (apologies to @BRRABill ), what is the "hyperconverged" equivalent in the XenServer world?
To all you XS experts, what is the "hyperconverged" equivalent in the XenServer world?
Similar to Starwind in the Windows world
XenServer is natively that in the Xen world. Nothing additional needed.
If you had 2, 3 or more XS bare metal installs with local drives, how do you "hyperconverge" all the local disks?
Are you saying with XS the "hyperconvergence" just auto-magically happens?
Of course not, but it doesn't for any platform. If you're setting up a greenfield situation, then you design it from the ground up with XS with single shared storage.
Let's try this again:
In Windows, you can take multiple boxes, add Starwind or Datacore = hyperconverged using local storage (no SAN needed).
How do you do the same thing with XS?
This can do HC for XenServer:
http://www.atlantiscomputing.com/products/atlantis-usxIt's interesting how much of Xen did they sell.
You mean how much of their sales is XenServer vs VMware? (since they support both)
-
@BRRABill autoboot issue fixed: https://github.com/vatesfr/xo-web/issues/879
Will be released in 4.16. Thanks for the report!
-
@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.
-
@BRRABill said:
@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.
You are probably correct.
-
@BRRABill said:
@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.
-
@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.
-
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.
-
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?
-
-
- 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.
- 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.
-
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.
-
Yeah I am wondering why it would assume
a) I wanted to migrate and
b) I had another server to migrate to -
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.
