Hyper-V as a service
-
@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.
Ah, that would make sense. Sorry I supposed I was being unintentionally obtuse.
-
@coliver said:
@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.
Ah, that would make sense. Sorry I supposed I was being unintentionally obtuse.
LOL don't sweat it - until this morning, I was running from an expectation that you could move that VM to another host. Come to find out this morning that you can't.
That whole discussion came from my earlier post about how to migrate two bare metal servers to two new Hyper-V (or any hypervisor) using only the hardware on hand (those two servers in question).
-
@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.
-
@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.
-
@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.
What is the difference between a GUI and command line? they are jsut two ways to do the same thing.
I performed half of the tasks in my weekend Exchange 2013 migration via powershell and the other half in the GUI. using dom0 is no different.
-
@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.
-
-
@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.
-
@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.
-
@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.
-
@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.
