Why Install Hyper-V via Role Rather than Pure Hyper-V
-
The reason that the metrics would be misleading is.... this example.
Customer A is yours. They are current on Windows 2019 licensing. You deploy Hyper-V with licensing encumbrance. In five years they decide that Windows doesn't need the constant updates. They drop SA. You fire them for not being on the latest version.
Now another MSP picks them up and gets stuck with the encumbered Hyper-V. The customer suffers the problem of Hyper-V being unable to be reasonably updated for free. They don't show up in your metrics because you fired them, but the original deployment of Hyper-V is what led them to the situation that they are in.
As an MSP that regularly has to clean up for that very scenario, I can tell you, even if you can avoid it, it's a huge industry issue.
-
So if the metric is "does it affect our customers", you can make that answer be "no" because they are no longer your customers by definition if they have that problem.
But if the metric is "does the decision affect your customers in the future" the answer can be "yes" because at the time of the decision, the people for whom the decision is being made are your customers and can be affected.
The decision can be problematic, but by firing the customer you can relegate the problem to only becoming an impact after they are no longer your customer. But the decision that creates the risk that leads to the impact was made while they were a customer.
So it depends if you define the issue as happening at the time of the action, or at the time of the impact.
-
Just for Ghits and Siggles I did a side-by-side install using the previously linked but earlier version of Hyper-V Server 2019 and the GA bits of Server 2019 Datacenter installed in Server Core mode with just the Hyper-V Role enabled.
The only difference between them is about 1.1GiB of space on the VHDX file they were installed into. Given the number of additional roles that can be installed on DC the extra space is fairly reasonable.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
The reason that the metrics would be misleading is.... this example.
Customer A is yours. They are current on Windows 2019 licensing. You deploy Hyper-V with licensing encumbrance. In five years they decide that Windows doesn't need the constant updates. They drop SA. You fire them for not being on the latest version.
Now another MSP picks them up and gets stuck with the encumbered Hyper-V. The customer suffers the problem of Hyper-V being unable to be reasonably updated for free. They don't show up in your metrics because you fired them, but the original deployment of Hyper-V is what led them to the situation that they are in.
As an MSP that regularly has to clean up for that very scenario, I can tell you, even if you can avoid it, it's a huge industry issue.
SAM we're on a totally different plane here.
Suffice it to say, we have our methods of operating and doing business. We have done well by them as have our clients/customers.
Getting into the details of the how/what/where/when/why of licensing, client management, and all of the peripheries associated is something to be had over a libation not a forum.
-
@PhlipElder said in Hyper-V 2019 on a domain:
The only difference between them is about 1.1GiB of space on the VHDX file they were installed into. Given the number of additional roles that can be installed on DC the extra space is fairly reasonable.
1.1GB is the entire size of an OS. That's pretty significant. When we are talking purely "extra software that isn't needed", it's a big number. Yes, Windows has a bit of bloat already which makes it seem like a reasonable extra percentage, I think that this is pretty misleading. 1.1GB is absolute terms is enormous, about the size we wish the entire thing was. In relative terms it is a code surface increase of 21.5%. So either way you look at it, it's huge.
It's not just that it is 21.5% more code, it's 21.5% less important code getting far less attention, less care, less oversight. So way more than 21.5% of the risk. And given the increasing concerns with Windows patch management in the last couple years, it is that much more acute than it was, say, in the 2012 era.
-
@PhlipElder said in Hyper-V 2019 on a domain:
Getting into the details of the how/what/where/when/why of licensing, client management, and all of the peripheries associated is something to be had over a libation not a forum.
The problem there, is that this is critical to decision making around how Hyper-V is deployed. The fact remains that there is a risk to that deployment method and the only way to avoid it is to force tech and business decisions and not allow the customers the freedom to decide what is best for them (or for you to do the same on their behalf.) It's the absolute number one factor in any Hyper-V discussion. If that shouldn't be had over a forum, this implies that Hyper-V is so problematic that our field shouldn't be considering it because it's not a business factor like it should be.
I don't agree with that, I think Hyper-V is an acceptable business product. But that means that the factors involved with how to manage it must be able to be approached like any business decision - be weighing costs, risks, benefits, and so forth. Nothing "business" can be moved from forum to libation, that implies an emotional approach (hobby) rather than analytical (business.)
I'm not saying that there aren't reasons for both approaches. There are, certainly. What I'm saying is that they can be analyzed on a case by case bases using standard business decision making to determine which approach is appropriate for any given situation.
-
@PhlipElder said in Hyper-V 2019 on a domain:
We have done well by them as have our clients/customers.
This is where it is difficult to say. Unless you've done this calculation taking this licensing into account, how can you or the customers know if the decisions were good?
I literally had a call an hour ago with a customer talking about this very thing (but related to email, not Hyper-V.) It's easy to say "this worked" in IT, but unless we evaluate "reasonable IT alternatives", we actually don't know if it "worked" in an IT context which requires a comparison against the alternatives. It's not enough to have functionality, you can get that without IT. It's getting a better decision process than you could get without good IT that makes it a success.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
Getting into the details of the how/what/where/when/why of licensing, client management, and all of the peripheries associated is something to be had over a libation not a forum.
The problem there, is that this is critical to decision making around how Hyper-V is deployed. The fact remains that there is a risk to that deployment method and the only way to avoid it is to force tech and business decisions and not allow the customers the freedom to decide what is best for them (or for you to do the same on their behalf.) It's the absolute number one factor in any Hyper-V discussion. If that shouldn't be had over a forum, this implies that Hyper-V is so problematic that our field shouldn't be considering it because it's not a business factor like it should be.
I don't agree with that, I think Hyper-V is an acceptable business product. But that means that the factors involved with how to manage it must be able to be approached like any business decision - be weighing costs, risks, benefits, and so forth. Nothing "business" can be moved from forum to libation, that implies an emotional approach (hobby) rather than analytical (business.)
I'm not saying that there aren't reasons for both approaches. There are, certainly. What I'm saying is that they can be analyzed on a case by case bases using standard business decision making to determine which approach is appropriate for any given situation.
SAM, I am no longer going to answer or address any of these comments/opinions. They have happened before and frankly I'm done with them.
TTFN
-
@PhlipElder - do you require all your customers to buy SA? What if one of them says - no we don't want it?
Not having SA doesn't make them license illegal - it just means they can't move to the new version.
-
@Dashrender said in Why Install Hyper-V via Role Rather than Pure Hyper-V:
Not having SA doesn't make them license illegal - it just means they can't move to the new version.
...without buying it again. Which is implied, but needs to be said. Lots of shops commonly update, but not with SA, because they delay or skip versions. That's a common tactic and lots of shops like it because they stay legal and supported, but don't pay as much as SA. It can be a totally valid business decision because it saves money potentially and meets the specific business' need and allows for a sustainable maintenance plan.
It's pretty rare, I think, that that pans out in the big scope as the better approach. But it is legal, valid, and in limited settings the correct choice. The most common places for that is when versions are "locked" do to vendor obligations and updating the license wouldn't change what version can be deployed.
-
@PhlipElder you must realize the way you /your business or owners operate is the opposite of the best interest of everyone. Including you / your business and owners.
Forcing SA onto a client doesn't make sense, especially since the client may not ever want to upgrade.
Installing Windows server, and then the Hyper-v role is ass backwards as well, since by license the VM (as you can only have 2 installs of Standard on a box per license, without additional licenses) means that the 2 VM are bound to that box. And if that box dies, you need to purchase a new license for the new Hyper-V box.
(Someone correct me if I'm wrong about the above licensing )
Where as by installing Hyper-V and just assinging your license to that, do you gain license mobility.
-
@DustinB3403 said in Why Install Hyper-V via Role Rather than Pure Hyper-V:
Installing Windows server, and then the Hyper-v role is ass backwards as well, since by license the VM (as you can only have 2 installs of Standard on a box per license, without additional licenses) means that the 2 VM are bound to that box. And if that box dies, you need to purchase a new license for the new Hyper-V box.
They are bound the box equally either way. If the box dies, both VMs as well as the Hyper-V install can be moved. In either case, the two VMs are box bound and bound together. So that part is equal regardless of approach.
Now if you have more on the box and the box dies but you want some additional mobility options, then this would be more limiting.
-
Mobility limitation example...
Server 1: Hyper-V as role, two Windows VMs, many non-Windows VMs. (This is a common scenario we see.)
Then capacity gets high and you want to reshuffle workloads. A new server is purchased either as a replacement or as a load increase.
Now as long as the original box is running, the Windows VMs are stuck on it and cannot move. All other workloads are free to move wherever they make sense. It requires no licensing nor does it require any human overhead to consider how licensing is affected. But the Windows VMs are locked for no reason, simply reducing the flexibility of the solution. Putting a free Hyper-V install on another server would not free them up to move there.
-
This topic reminds me of every topic of someone attempting to justify their IPoD that they were sold.
-
Or this : https://smbitjournal.com/2014/07/it-worked-for-me/
Like who can honestly justify these decisions? You're burying your head in the sand and hoping nothing bad happens.
