Hyper-V as a service
-
@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.
-
@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?
-
@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.
And assuming this is true, I'm guessing you can't migrate this VM to another host.
Consider the following scenario. Two servers, both installed bare metal Server 2012. One has AD, the other Exchange.
Assuming no other hardware exists, how would you virtualize this?
I think I found my answer while typing this - first we need some assumptions, both hardware hosts have enough storage/CPU/RAM to host both servers work loads, even if at reduced capacity (i.e. 4 GB RAM instead of 8, etc).
Install Hyper-V service on server1
perform P2V of server2 to server1
format server2 install Hyper-V Server on bare metal
migrate previously P2V'ed server to server2
uninstall Hyper-V service on server1
perform P2V of server1 to server2
format server1, install Hyper-V Server on bare metal
Migrate VM of server1 back to hardware of server1 -
The dom0 is not a VM on any Hypervisor. Why would this be different for Hyper-V?
-
@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.
And assuming this is true, I'm guessing you can't migrate this VM to another host.
Consider the following scenario. Two servers, both installed bare metal Server 2012. One has AD, the other Exchange.
Assuming no other hardware exists, how would you virtualize this?
I think I found my answer while typing this - first we need some assumptions, both hardware hosts have enough storage/CPU/RAM to host both servers work loads, even if at reduced capacity (i.e. 4 GB RAM instead of 8, etc).
Install Hyper-V service on server1
perform P2V of server2 to server1
format server2 install Hyper-V Server on bare metal
migrate previously P2V'ed server to server2
uninstall Hyper-V service on server1
perform P2V of server1 to server2
format server1, install Hyper-V Server on bare metal
Migrate VM of server1 back to hardware of server1Correct.
-
@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.
-
@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.
-
@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.
-
@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.
This was my understanding as well. But I'm equally willing to be wrong on this point
-
@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.
It can't? You generally do access it on a number of occasions. Dom0 in Xen runs the management tool stack and the management interface. XenServer's Dom0 is accessed via the CLI and XenCenter. Hyper-V Server's Dom0 is a special version of Windows Core that you access either by ps-remoting or RDP. Dom0 is just another VM with special drivers and a special kernel to interact with the underlying hypervisor and hardware.
-
@JaredBusch said:
Dom0 may technically be a VM, but it is not a guest VM that can be interacted with in any fashion.
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. -
@coliver said:
@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.
It can't? You generally do access it on a number of occasions. Dom0 in Xen runs the management tool stack and the management interface. XenServer's Dom0 is accessed via the CLI and XenCenter. Hyper-V Server's Dom0 is a special version of Windows Core that you access either by ps-remoting or RDP. Dom0 is just another VM with special drivers and a special kernel to interact with the underlying hypervisor and hardware.
It cannot be interacted with as a guest VM
-
@JaredBusch said:
@coliver said:
@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.
It can't? You generally do access it on a number of occasions. Dom0 in Xen runs the management tool stack and the management interface. XenServer's Dom0 is accessed via the CLI and XenCenter. Hyper-V Server's Dom0 is a special version of Windows Core that you access either by ps-remoting or RDP. Dom0 is just another VM with special drivers and a special kernel to interact with the underlying hypervisor and hardware.
It cannot be interacted with as a guest VM
It is a guest VM... Just one that is required for the operation of specific hypervisors. I don't understand the distinction.
-
@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.
-
@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.
