Why Install Hyper-V via Role Rather than Pure Hyper-V
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder By far the biggest reason that most of us avoid that installation method is the one that you are avoiding mentioning - licensing. What the licensing is for Hyper-V and Windows today isn't relevant to the concern, it is how it will be licensed indefinitely into the future. This is what customers often don't understand and overlook thinking that because they already paid for Windows that they should "just use it", and then routinely get burned down the road by being unable to upgrade Hyper-V without paying for it, because they encumbered it out of habit and no one warned them that this risk would almost certainly catch them when they didn't want to spend more money to upgrade something that is otherwise free.
By deploying Hyper-V in the lighter mode, we simply protect the customer from an unnecessary encumbrance, once that we've found to be the most significant factor affecting Hyper-V decision making in the real world.
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
I don't know what a "control VM" is?
-
@PhlipElder said in Hyper-V 2019 on a domain:
I don't know what a "control VM" is?
That's what we are discussing - how the VM that controls Hyper-V is managed. Dom0 in Xen terms. Parent partition. Lots of names for it. But it is a VM that runs on top of Hyper-V and provides the interfaces to the outside world on behalf of Hyper-V that has no interface on its own, and provides control and management of Hyper-V.
-
@PhlipElder said in Hyper-V 2019 on a domain:
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.
Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.
-
@PhlipElder said in Hyper-V 2019 on a domain:
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.
Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.
You are in a miraculous situation. For most everyone, clients don't have 100% software assurance (or purchase updates immediately on release every time.) It is not in any way normal to have 100% always current licensed customers. Literally have never heard of any MSP claim that level of saturation before, it is that rare.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.
Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.
You are in a miraculous situation. For most everyone, clients don't have 100% software assurance. It is not in any way normal to have 100% always current licensed customers. Literally have never heard of any MSP claim that level of saturation before, it is that rare.
We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.
-
@PhlipElder said in Hyper-V 2019 on a domain:
We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.
You would drop clients simply because they don't see the price of being always at the latest version as being a good business decision for them? Even when they are correct? Because, while it is almost always good, it isn't always.
Being "licensed correctly" and "always on the latest" aren't the same concept.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
Moot point for us as all of our clients run either Software Assurance or we are supplying the licenses via SPLA as we manage their infrastructure.
If you can truly control that, we find that clients tend to like to drop SA or avoid it over time. They might start with it, but it only takes dropping it once to cause an issue. And if Hyper-V is the "one reason" why they would need it, they then see Hyper-V as a problem. It's just easier and more consistent to avoid the problem and not have to have the more complex decision structure.
Our longest standing client is spanning two decades. We have not had any issue with software licensing with our clients. None. Nadda. Zippo.
You are in a miraculous situation. For most everyone, clients don't have 100% software assurance (or purchase updates immediately on release every time.) It is not in any way normal to have 100% always current licensed customers. Literally have never heard of any MSP claim that level of saturation before, it is that rare.
We operate our business 100% above board and expect any company/client/customer we work with to operate the same way.
We will never work with a company that sees software as something they can pilfer at will.
-
@PhlipElder said in Hyper-V 2019 on a domain:
We operate our business 100% above board and expect any company/client/customer we work with to operate the same way.
We will never work with a company that sees software as something they can pilfer at will.Same here, but that's unrelated to the discussion we are having of always being at the latest possible version.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.
You would drop clients simply because they don't see the price of being always at the latest version as being a good business decision for them? Even when they are correct? Because, while it is almost always good, it isn't always.
Being "licensed correctly" and "always on the latest" aren't the same concept.
Huh?
-
@PhlipElder said in Hyper-V 2019 on a domain:
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.
You would drop clients simply because they don't see the price of being always at the latest version as being a good business decision for them? Even when they are correct? Because, while it is almost always good, it isn't always.
Being "licensed correctly" and "always on the latest" aren't the same concept.
Huh?
We are discussing how your clients never get stuck on an older version of Windows. You can get, for example, 2012 R2 licensing and run that for many, many years (and still be supported, even) and be completely licensed, but not current.
-
That's the most common scenario we see, clients who are stuck on 2012R2. Fully licensed, but not current. And someone tied their Hyper-V to that license when they shouldn't have, and now they've gone years without being able to update Hyper-V purely because of how it was deployed, even though Hyper-V itself is free.
-
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
@scottalanmiller said in Hyper-V 2019 on a domain:
@PhlipElder said in Hyper-V 2019 on a domain:
We have a very simple policy: Not licensed correctly? Either get there with a commitment and we will help them get there or we walk. Period.
You would drop clients simply because they don't see the price of being always at the latest version as being a good business decision for them? Even when they are correct? Because, while it is almost always good, it isn't always.
Being "licensed correctly" and "always on the latest" aren't the same concept.
Huh?
We are discussing how your clients never get stuck on an older version of Windows. You can get, for example, 2012 R2 licensing and run that for many, many years (and still be supported, even) and be completely licensed, but not current.
Where did I say that?
Our clients run Software Assurance for both the ability to be flexible for an upgrade but there are other benefits to SA beyond that. So, I don't get that point?
I said "correctly". That has nothing to do with SA and keeping current.
-
@PhlipElder said in Hyper-V 2019 on a domain:
I said "correctly". That has nothing to do with SA and keeping current.
Your statement only makes sense if correctly is your way to say currently. The entire point that you were discussing is about being current. So if you were responding to me, it had to mean current. If you weren't responding to me, then let's back up.
We are back to... how do you guarantee that Hyper-V is always current and free for customers if it is tied to their Windows licensing? that it is licensed "correctly", meaning legally, that doesn't provide for that. We all have that, and it still has the issue we are trying to protect again.
Only being 100% current, 100% of the time solves the issue. Now if you have 100% SA on every client and will drop them always if they ever decide that SA isn't for them... then okay, you maintain current for your current customers, but only by firing customers who aren't current rather than by giving them the flexibility to make the business decisions that they feel are right for them. That's fine, but it makes the metrics potentially misleading.
-
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.
