Hyper-V as a service
-
@coliver said:
@Dashrender said:
@coliver said:
@Dashrender said:
@BRRABill said:
@JaredBusch said:
To continue on that point, while it is good to know what dom0 actually is for some people, there is no need for most to even have to think about it because of this. There is nothing that you can do to dom0 like you do with a guest VM.
You interact with dom0 as if it was the OS, because that is how it is designed to be interacted with.The day I stopped thinking about this was the day my life got easier.
So how do you think about it? Having a GUI is what makes it the most confusing to me. If dom0 was just a command line, I think it would appear easier.
Huh... that just seems strange to me.
it's a tit for tat thing - you live in a command line world... I live in a GUI world.. so we see things from opposite sides.. then again, you may never have confusion being from the CLI side.. who knows.
I'm a Windows Admin by trade and a Linux admin by hobby. CLI and GUI are both legitimate forms of management and configuration. It seems odd, to me, that the way you access something signifies its function.
Oh it shouldn't. But when you're a hammer, everything is a nail - so seeing one thing leads you to incorrect assumptions, because - human nature.
-
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Anyone know what state a Windows Server is left in when you uninstall Hyper-V when it's installed as a service?
It changes the boot pointer and the OS boots normally as if Hyper-V was never there.
So when you install the Hyper-V service, the underlying disk partitions are changed (shrank) to allow a new partition to be created for Hyper-V to run from?
If you have Server2012R2 or Windows 8.1/10 and enabled the Hyper-V role there is no visible change to anything from within Windows. You just now have the ability to make VMs.
I wonder then, how does this work fundamentally? The underlying system is suppose to be booting from Hyper-V, not Windows server. Is it just changing from booting from ntkernal to something else then?
Exactly the same as Xen does it. By changing the boot pointer.
-
@JaredBusch said:
The dom0 is not a VM on any Hypervisor. Why would this be different for Hyper-V?
It is on Xen. What do you mean?
-
@scottalanmiller said:
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Anyone know what state a Windows Server is left in when you uninstall Hyper-V when it's installed as a service?
It changes the boot pointer and the OS boots normally as if Hyper-V was never there.
So when you install the Hyper-V service, the underlying disk partitions are changed (shrank) to allow a new partition to be created for Hyper-V to run from?
If you have Server2012R2 or Windows 8.1/10 and enabled the Hyper-V role there is no visible change to anything from within Windows. You just now have the ability to make VMs.
I wonder then, how does this work fundamentally? The underlying system is suppose to be booting from Hyper-V, not Windows server. Is it just changing from booting from ntkernal to something else then?
Exactly the same as Xen does it. By changing the boot pointer.
I need more information - this doesn't really explain much. Changes it to point to what?
-
@JaredBusch said:
@coliver said:
@JaredBusch said:
The dom0 is not a VM on any Hypervisor. Why would this be different for Hyper-V?
dom0 is a VM, just a privileged one with drivers to interact with the underlying hardware that the hypervisor passes through.
@Dashrender said:
@JaredBusch said:
The dom0 is not a VM on any Hypervisor. Why would this be different for Hyper-V?
Because Scott has claimed differently for darn near ever. that enabling the Hyper-V service installs Hyper-V under the current OS, making that OS the first VM on the system.
Dom0 may technically be a VM, but it is not a guest VM that can be interacted with in any fashion.
Correct, it's a VM but not a guest VM. It's very unique to the install and can't be moved or anything. It's what you "see" when you think you are seeing the hypervisor.
-
@Dashrender said:
@JaredBusch said:
en have to think about it because of this. There is nothing that you can do to dom0 like you do with a guest VM.
I think what JB is saying is that you can't move it to another VM Host like you can any other guest VM. It's tied to the hardware. If you did move it, the whole server would just die.
More importantly, you would never want to move it or have any reason to look into that. The bigger issue is... outside of a purely technical understanding of limitations, why would you care? The way that it works would make it very dangerous to move to another host as it is hardware specific.
-
@Dashrender said:
@BRRABill said:
@JaredBusch said:
To continue on that point, while it is good to know what dom0 actually is for some people, there is no need for most to even have to think about it because of this. There is nothing that you can do to dom0 like you do with a guest VM.
You interact with dom0 as if it was the OS, because that is how it is designed to be interacted with.The day I stopped thinking about this was the day my life got easier.
So how do you think about it? Having a GUI is what makes it the most confusing to me. If dom0 was just a command line, I think it would appear easier.
Why? That's odd. A shell is a shell, right?
-
@BRRABill said:
@Dashrender said:
So how do you think about it? Having a GUI is what makes it the most confusing to me. If dom0 was just a command line, I think it would appear easier.
That's actually one of the reasons I decided on XS.
Install XS and install VMs. No Windows GUI to make it more confusing to me.
But there CAN BE a Linux GUI if you want. (Trust me, you don't want, but you can just like Hyper-V.)
It's only cultural that Hyper-V is considered to have one and Xen is not. They are identical in this (and many other) ways.
-
@Dashrender said:
@coliver said:
@Dashrender said:
@BRRABill said:
@JaredBusch said:
To continue on that point, while it is good to know what dom0 actually is for some people, there is no need for most to even have to think about it because of this. There is nothing that you can do to dom0 like you do with a guest VM.
You interact with dom0 as if it was the OS, because that is how it is designed to be interacted with.The day I stopped thinking about this was the day my life got easier.
So how do you think about it? Having a GUI is what makes it the most confusing to me. If dom0 was just a command line, I think it would appear easier.
Huh... that just seems strange to me.
it's a tit for tat thing - you live in a command line world... I live in a GUI world.. so we see things from opposite sides.. then again, you may never have confusion being from the CLI side.. who knows.
I don't see how this makes sense. Are you saying that we, living in the CLI world, would be expected to see a GUI and feel like that is not the OS but be confused if we saw a command line? What about seeing an API?
What do you consider vSphere? That's a GUI presented through an API connection. Like XO and XenCenter.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Anyone know what state a Windows Server is left in when you uninstall Hyper-V when it's installed as a service?
It changes the boot pointer and the OS boots normally as if Hyper-V was never there.
So when you install the Hyper-V service, the underlying disk partitions are changed (shrank) to allow a new partition to be created for Hyper-V to run from?
If you have Server2012R2 or Windows 8.1/10 and enabled the Hyper-V role there is no visible change to anything from within Windows. You just now have the ability to make VMs.
I wonder then, how does this work fundamentally? The underlying system is suppose to be booting from Hyper-V, not Windows server. Is it just changing from booting from ntkernal to something else then?
Exactly the same as Xen does it. By changing the boot pointer.
I need more information - this doesn't really explain much. Changes it to point to what?
The other kernel. The same as you do when you have multiple kernels. No different than dual booting any two systems. This can apply to Windows and Linux on the same box. It can apply to Linux with multiple kernels. This is a standard pointer that every boot loader deals with.
So in the case of Xen, you have the Linux kernel or the Xen hypervisor kernel. It just chooses to boot one or the other. With Hyper-V it can point to the HV Kernel or the NTKernel.
-
@scottalanmiller said:
But there CAN BE a Linux GUI if you want. (Trust me, you don't want, but you can just like Hyper-V.)
Just for educational purposes, why is this?
-
@BRRABill said:
@scottalanmiller said:
But there CAN BE a Linux GUI if you want. (Trust me, you don't want, but you can just like Hyper-V.)
Just for educational purposes, why is this?
Same reasons as with Hyper-V minus the benefits that Hyper-V has of having lots of people that do this and a few tools that are used for the purpose. There isn't any "local Xen console" interface like Hyper-V has. So all of the negatives of Hyper-V with a GUI, none of the benefits. Plus, there are great API based tools like XC and XO, so no need for it.
-
@scottalanmiller said:
Same reasons as with Hyper-V minus the benefits that Hyper-V has of having lots of people that do this and a few tools that are used for the purpose. There isn't any "local Xen console" interface like Hyper-V has. So all of the negatives of Hyper-V with a GUI, none of the benefits. Plus, there are great API based tools like XC and XO, so no need for it.
I thought you were making a general statement on GUIs on Linux servers.
XC/XO has been fine for me.
-
@BRRABill said:
@scottalanmiller said:
Same reasons as with Hyper-V minus the benefits that Hyper-V has of having lots of people that do this and a few tools that are used for the purpose. There isn't any "local Xen console" interface like Hyper-V has. So all of the negatives of Hyper-V with a GUI, none of the benefits. Plus, there are great API based tools like XC and XO, so no need for it.
I thought you were making a general statement on GUIs on Linux servers.
XC/XO has been fine for me.
No different than GUIs anywhere on servers.
-
This thread made me finally realize why @mdecamp was having issues with me wanting to use "Hyper-V" to shutdown a Hyper-V machine and its hosts.
I was always accessing Hyper-V via the GUI. Via the GUI using the Eaton software to send shutdown to Hyper-V is possible. (Though is it legal license-wise, I wonder?) But a lot of people probably only know it in its non-GUI version, like other hypervisors.
So I would imagine there would be no way to install the shutdown software into it. (Or XS, or any other hypervisor for that matter.)
-
@BRRABill said:
This thread made me finally realize why @mdecamp was having issues with me wanting to use "Hyper-V" to shutdown a Hyper-V machine and its hosts.
I was always accessing Hyper-V via the GUI. Via the GUI using the Eaton software to send shutdown to Hyper-V is possible. (Though is it legal license-wise, I wonder?) But a lot of people probably only know it in its non-GUI version, like other hypervisors.
So I would imagine there would be no way to install the shutdown software into it. (Or XS, or any other hypervisor for that matter.)
WHAT?
-
@BRRABill That makes no sense. Even if you couldn't install software on them (you can), every OS has well-known remote shutdown/restart procedures.
-
@travisdh1 said:
@BRRABill That makes no sense. Even if you couldn't install software on them (you can), every OS has well-known remote shutdown/restart procedures.
Perhaps I was unclear. That was pre-coffee.
The was trying to decide between the 5S and the 5P. The 5S only communicates with the machine via USB. The 5P can communicate via network interface as well.
If you are able to plug the UPS into a machine via UPS, and install the Windows-based "UPS Companion Software", you can shut down that machine. If it was a server running Hyper-V (with the GUI) that would work.
However, this scenario would have no way of contacting the VMs. The 5S only works via UPS cable and the companion software.
So to shutdown the VMs, you would need the 5P which sends the shutdown signal over the network to the software sitting on each VM.
Does that make more sense. Someone I will not mention called my first post "babbling" or "rambly" or something, so hopefully this makes more sense!
-
@travisdh1 said:
every OS has well-known remote shutdown/restart procedures.
Though you could be right even the 5S via USB cable might work even WITHOUT the companion software.
Hmmm, time for a new thread!
-
@BRRABill You seriously need to slow down and think a little.
Half the time you typed UPS, I think you meant USB.
I have no idea if the Eaton client software can be installed on Hyper-V Server, but I can test that. It will come down to what Windows features it requires. The software installs and runs as a service that you access via a browser (even on the local machine), so I would see no reason why it would not install.
Regarding the 5P, it does NOT have a network card by default. The network card is an optional add on that costs $250.
