RAID fumble.
-
Many RAID controllers do not offer RAID expansion or only for certain types of RAID (generally parity RAID as an expansion is a standard parity rebuild operation.) RAID 10 has no obvious method in the standard RAID operations so a controller has to have a complex method to handle this. At a minimum a lot of cache is needed to handle it. It's a pretty rare feature.
If you are virtualized you can just copy off, rebuild, copy on and you are good to go.
-
I have 2012 R2 Standard installed on the host but run all workloads in VMs. So I'll have to reconstruct the RAID and then reinstall the OS it sounds like.
-
@creayt said:
I have 2012 R2 Standard installed on the host but run all workloads in VMs.
Are you using VirtualBox? You should avoid type 2 hypervisors. Use HyperV instead. Then you don't have the fragility of running an OS on the bare metal and far better stability and performance. You never want an OS "on the bottom" of the stack.
-
I'm using Hyper V, but as a role in Server 2012 R2. We don't have the expertise to run the standalone Hyper V Server.
VirtualBox is gross btw.
-
@creayt said:
VirtualBox is gross btw.
Only if you need professional level virtualization. I still use it on my laptop because it's easier and I never bothered to look and see if Hyper-V comes with 8.1 Home Edition (I know I can't remote desktop into my 8.1 Home box!).
-
@creayt said:
I'm using Hyper V, but as a role in Server 2012 R2. We don't have the expertise to run the standalone Hyper V Server.
The role thing really gets people. There is no such thing as running HyperV on Windows Server, it looks that way but technically cannot happen. The "role" is not a role but is just a tool that introduces a shim and installs HyperV to the bare metal and then runs the Windows Server that you are looking at in a VM. It's all on HyperV, nothing on Windows. There is no exception to this. It just looks like something else.
This is a trick to make things "easier" that MS learned from the early Xen deployments.
-
@dafyre said:
@creayt said:
VirtualBox is gross btw.
Only if you need professional level virtualization. I still use it on my laptop because it's easier and I never bothered to look and see if Hyper-V comes with 8.1 Home Edition (I know I can't remote desktop into my 8.1 Home box!).
VirtualBox does not force your main OS to be virtualized. So for a desktop or laptop use, VirtualBox is generally superior to HyperV which makes your main OS be a VM too.
-
@scottalanmiller said:
The role thing really gets people. There is no such thing as running HyperV on Windows Server, it looks that way but technically cannot happen. The "role" is not a role but is just a tool that introduces a shim and installs HyperV to the bare metal and then runs the Windows Server that you are looking at in a VM. It's all on HyperV, nothing on Windows. There is no exception to this. It just looks like something else.
This is a trick to make things "easier" that MS learned from the early Xen deployments.
So what, once I've installed Hyper-V on my Windows Server 2012 R2 box, it essentially becomes the dom0 equivalent in Xen?
-
@dafyre said:
So what, once I've installed Hyper-V on my Windows Server 2012 R2 box, it essentially becomes the dom0 equivalent in Xen?
Yes, that's absolutely exactly what it does.
-
@scottalanmiller said:
The role thing really gets people. There is no such thing as running HyperV on Windows Server, it looks that way but technically cannot happen. The "role" is not a role but is just a tool that introduces a shim and installs HyperV to the bare metal and then runs the Windows Server that you are looking at in a VM. It's all on HyperV, nothing on Windows. There is no exception to this. It just looks like something else.
Do you have some links to documentation on this?
If what you're saying is true, there are some weird implications:
-
The host OS "vm" has the special privilege of seemingly-unvirtualized/full access to its hardware resources and does not allow for any granular allocation/limitation on things like processor weighting or RAM ( for example, this special VM can see the real network adapters, not virtualized ones like all of the VMs do ).
-
All other VMs are dependent on this new host VM to run. They cannot run if the host OS isn't up and running. Correct me if I'm wrong.
-
The underlying files that run the host VM's OS are still on the main-level of the drive hardware, so not encapsulated into a .vhd, right?
I'm not saying you're wrong, I'm just saying that it's fascinating and I'd like to learn more. It's especially interesting because Windows 8.1 ( even Home I believe ) supports Hyper V so if it's converting the existing host OS into a VM it somehow maintains full, unthrottled performance in that new host VM and fully utilizes the real hardware drivers ( such as video ).
-
-
@creayt said:
Do you have some links to documentation on this?
https://en.wikipedia.org/wiki/Hyper-V
https://technet.microsoft.com/library/cc816638(WS.10).aspx
Microsoft has been super clear on HyperV being a native / bare metal / type 1 hypervisor since day one. Only this type of hypervisor is considered remotely acceptable for server virtualization. HyperV is part of the big four enterprise type 1 hypervisors: VMware ESXi, HyperV, KVM and Xen.
-
@creayt said:
- The host OS "vm" has the special privilege of seemingly-unvirtualized/full access to its hardware resources and does not allow for any granular allocation/limitation on things like processor weighting or RAM ( for example, this special VM can see the real network adapters, not virtualized ones like all of the VMs do ).
Yes, that is correct. That's what @dafyre and I were talking about in comparing to the Dom0. The "control" VM or the Dom0 has special access used for drivers, monitoring, etc. Microsoft, to make this "easier" for people refers to this VM as the "physical" VM, even though it is obviously not physical and cannot be without making the product a toy like VirtualBox would be.
-
@creayt said:
- All other VMs are dependent on this new host VM to run. They cannot run if the host OS isn't up and running. Correct me if I'm wrong.
Correct. Again modeled directly off of how Xen and ESXi 4 and earlier were designed. There is nothing even slightly abnormal here.
-
@creayt said:
- The underlying files that run the host VM's OS are still on the main-level of the drive hardware, so not encapsulated into a .vhd, right?
Correct, it reads them raw.
-
@creayt said:
I'm not saying you're wrong, I'm just saying that it's fascinating and I'd like to learn more. It's especially interesting because Windows 8.1 ( even Home I believe ) supports Hyper V so if it's converting the existing host OS into a VM it somehow maintains full, unthrottled performance in that new host VM and fully utilizes the real hardware drivers ( such as video ).
It does not, it loses performance and this is why VirtualBox is considered superior for that type of use since it is a Type 2 hypervisor, not a Type 1.
-
At the time that HyperV was designed, there was only one architecture for enterprise type 1 virtualization: hypervisor with a "control" or "Dom0" driver environment. All three players, Xen, VMware and HyperV, did the exact same thing. Xen and HyperV have never varied from this.
In the time since then, KVM emerged with having the hypervisor itself contain all of the drivers and extra components and VMware ESXi 5 was completely overhauled to move to that model. So now, the field is 50/50 having or not having a control environment separate from the hypervisor kernel and the two camps argue as to which design is better (one is faster, in theory, and the other is more stable and safe - but in reality Xen continues to have performance advantages that the other three lack.)
-
Microsoft and VMware both made VirtualBox competitors back in the day. Microsoft VirtualPC and Virtual Server 2005 were both type 2 hypervisors. VMware made GSX and later VMware Server. These were type 2 (run on top of an OS) and were abysmally slow and VMware's offerings were buggy. VMware still offers the silly Workstation product that I can't believe anyone would buy. And on the Mac it is popular to use Fusion, Parallels and other type 2 hypervisors.
But in reality, the Type 2 market is completely owned by Oracle with VirtualBox, it is the stand out leader in its field with the biggest market, most advanced code base and most active development.
-
@scottalanmiller said:
@creayt said:
I'm not saying you're wrong, I'm just saying that it's fascinating and I'd like to learn more. It's especially interesting because Windows 8.1 ( even Home I believe ) supports Hyper V so if it's converting the existing host OS into a VM it somehow maintains full, unthrottled performance in that new host VM and fully utilizes the real hardware drivers ( such as video ).
It does not, it loses performance and this is why VirtualBox is considered superior for that type of use since it is a Type 2 hypervisor, not a Type 1.
This stuff is blowing my mind! Very informative, thank you.
So is it safe to assume that if you uninstall Hyper V from say a Windows 8.1 Home laptop it reverts to the original pre-bare-metal-hypervisor state? Or does it stay in degraded performance mode for time and all eternity until the case of a full host OS reinstall?
-
@creayt said:
So is it safe to assume that if you uninstall Hyper V from say a Windows 8.1 Home laptop it reverts to the original pre-bare-metal-hypervisor state? Or does it stay in degraded performance mode for time and all eternity until the case of a full host OS reinstall?
Yes, it reverts.
Imagine that it is almost like dual booting. When HyperV is active it boots to HyperV secretly, then fires up Windows 8.1 in a VM and shows you the console directly to the screen so that, other than the performance loss, you can't tell what it has done.
If you remove HyperV, the boot loader just points directly to the Windows 8.1 install rather than the HyperV install and Windows 8.1 boots without knowing that HyperV isn't there or that it used to be, to Windows 8.1 it is always booting on its own like normal.
So it is like dual booting trickery combined with console redirects.
-
I see.
So as far as it working this way, compared to just running as a layer on top of the host OS like type 2 does, is there anything worth thinking about / applicable to any decision making beyond "if we run it this way, the performance of the host won't be as good as its specs would indicate"?
Also, is there a way to guess/gauge how much of a performance hit the host will have w/ type 1?
Also, is the host VM's performance almost equivalent to the full host's hardware resources, or closer to a pretty limited VM?