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. At home in my little lab, I have Hyper-V installed, as everyone recommends, on the bare metal.
I know that I can create VMs and such with Powershell. Once you start a VM, the, obviously you need to install its OS. To go through the installer, you must somehow connect to the VM. The only I can see to do that is to connect to the Hyper-V host with Hyper-V manager (going through the rigmarole involved with non-domain machines connecting to one another), which allows you to basically look at a console and go through the installer. Seems like this would apply to a Linux OS as well, since until the OS would need to be functioning for SSH. Are there other / better ways?
-
You would use Hyper-V Manager on another computer, such as your Win10 computer.
Win10 comes with Server Manager built in. You can add your Hyper-V server in there, and manage it.
There's also RSAT.
-
There's also 5nine Hyper-v manager.
-
That's what I thought. For that initial install of the OS, you have to have some manager program.
-
@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.
-
@Tim_G said in Managing Hyper-V VMs:
There's also 5nine Hyper-v manager.
Tagging @5nine since they are here in the community
-
@EddieJennings said in Managing Hyper-V VMs:
That's what I thought. For that initial install of the OS, you have to have some manager program.
That's how it works with every hypervisor. To "go into" the VM, you need to use a manager.
Like with KVM, you can use qemu/virt-manager.
Hyper-V, you use Hyepr-V Manager.
VMWare, vsphere.
-
@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.
-
@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.
