Managing Hyper-V VMs
-
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
At work, all of the servers with VMs have Hyper-V provided as a service of Windows server, rather than Hyper-V installed on the bare metal.
Hyper-V is always on bare metal. There is no possible exception to that. It's just whether you have a full, licensed, unnecessary bloat of Windows in the Dom0 or if you have something lean and free. But no matter what, Hyper-V itself is the same. Only the control VM changes.
Well, in that case I have Hyper-V installed on the bare metal from installing it as a role from the Server 2012 R2 GUI.
-
@EddieJennings said in Managing Hyper-V VMs:
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
At work, all of the servers with VMs have Hyper-V provided as a service of Windows server, rather than Hyper-V installed on the bare metal.
Hyper-V is always on bare metal. There is no possible exception to that. It's just whether you have a full, licensed, unnecessary bloat of Windows in the Dom0 or if you have something lean and free. But no matter what, Hyper-V itself is the same. Only the control VM changes.
Well, in that case I have Hyper-V installed on the bare metal from installing it as a role from the Server 2012 R2 GUI.
Yup, it's a type 1. Your punishment for that method is that your management VM is bloated slowing your system down and requiring more patches (and is obviously less safe), it requires that you maintain a license for it instead of being free, and you have to update the license to update Hyper-V instead of being able to update any time. But the Hyper-V on the bare metal remains the same.
-
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
Are there other / better ways?
The alternative approach, the one used by Azure and AWS, is to bake the install totally into an image and not to install each time but to replicate an image and then you connect to the working image. Nothing wrong with doing full installs like you are doing, but this is how the big clouds get around this limitation while not offering remote access options either.
Yeah. One thing I intend to do with my lab is learning how to clone VMs and learn other features and functions.
-
@EddieJennings said in Managing Hyper-V VMs:
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
Are there other / better ways?
The alternative approach, the one used by Azure and AWS, is to bake the install totally into an image and not to install each time but to replicate an image and then you connect to the working image. Nothing wrong with doing full installs like you are doing, but this is how the big clouds get around this limitation while not offering remote access options either.
Yeah. One thing I intend to do with my lab is learning how to clone VMs and learn other features and functions.
The best two ways are to either use a VM template, or Sysprep a VM, shut it down, and copy/paste the .VHDX and use the copy to create a new VM.
-
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
At work, all of the servers with VMs have Hyper-V provided as a service of Windows server, rather than Hyper-V installed on the bare metal.
Hyper-V is always on bare metal. There is no possible exception to that. It's just whether you have a full, licensed, unnecessary bloat of Windows in the Dom0 or if you have something lean and free. But no matter what, Hyper-V itself is the same. Only the control VM changes.
Well, in that case I have Hyper-V installed on the bare metal from installing it as a role from the Server 2012 R2 GUI.
Yup, it's a type 1. Your punishment for that method is that your management VM is bloated slowing your system down and requiring more patches (and is obviously less safe), it requires that you maintain a license for it instead of being free, and you have to update the license to update Hyper-V instead of being able to update any time. But the Hyper-V on the bare metal remains the same.
As with everything in my environment, this is what was inherited. I haven't decided whether or not it's really with blowing these servers away and reinstalling the "right" way.
I understand that Hyper-V is a type 1 hypervisor. It always seems odd to think about when it's "installed" from an existing OS and GUI.
-
@EddieJennings said in Managing Hyper-V VMs:
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
Are there other / better ways?
The alternative approach, the one used by Azure and AWS, is to bake the install totally into an image and not to install each time but to replicate an image and then you connect to the working image. Nothing wrong with doing full installs like you are doing, but this is how the big clouds get around this limitation while not offering remote access options either.
Yeah. One thing I intend to do with my lab is learning how to clone VMs and learn other features and functions.
Not that many people actually bother to do this. Just important to know that it is an option.
-
@EddieJennings said in Managing Hyper-V VMs:
I understand that Hyper-V is a type 1 hypervisor. It always seems odd to think about when it's "installed" from an existing OS and GUI.
Windows is just an "installer" in that case. It's important to understand that it shims Hyper-V underneath of itself and restarts as a VM. Otherwise, lots of other things end up being very confusing.
Xen has always worked the same way. Anything with the Dom0 model does. ESX did back when it was that way.
-
@EddieJennings said in Managing Hyper-V VMs:
As with everything in my environment, this is what was inherited. I haven't decided whether or not it's really with blowing these servers away and reinstalling the "right" way.
It very likely will be, I think. Because it is already a technological barrier for you (making you run one version old Hyper-V instead of current) it's a clear problem. Hyper-V is maturing fast and while 2012 R2 was decent, 2016 is much better. It is faster, more stable, more powerful, more secure and robust and will be easier to take to the next version, expected out next year.
-
@scottalanmiller said in Managing Hyper-V VMs:
@EddieJennings said in Managing Hyper-V VMs:
As with everything in my environment, this is what was inherited. I haven't decided whether or not it's really with blowing these servers away and reinstalling the "right" way.
It very likely will be, I think. Because it is already a technological barrier for you (making you run one version old Hyper-V instead of current) it's a clear problem. Hyper-V is maturing fast and while 2012 R2 was decent, 2016 is much better. It is faster, more stable, more powerful, more secure and robust and will be easier to take to the next version, expected out next year.
Ah, I didn't think of the barrier restricting me to 2012 R2.
-
@EddieJennings said in Managing Hyper-V VMs:
Ah, I didn't think of the barrier restricting me to 2012 R2.
Yeah, the misinstallation is anything but trivial. It sounds trivial, and in some ways it is for the first two years, but it gets worse and worse as time goes on. If it was only the bloat, then whatever, not great but you wouldn't be anxious to work around it. But it is licensing and risk.
Now that said, any effort that you can use to move to 2016 today, you can still do tomorrow. So you just need to think about the right time to make the change.
