Domain Controller Down (VM)
-
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
-
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
-
@Dashrender said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
Dedicating hardware to a single function is archaic.
No it's not.
The healthcare field has a handful of worthwhile usable applications, that only they know how to fix. If you're running on something using PV drivers that they don't understand, you're not going to get support, which you will probably need.
And... that's archaic. It's not that bad, incapable vendors don't require this. It's that that is archaic. Dedicated hardware is not the issue, but most healthcare software is downright embarassing and decades out of good practice and poorly supported or outright unsupported by the vendors.
Yep, they are both - super cheap on spending resources to keep their software up to date with modern design, and the government not certifying new OSs/software for medical use.
Example, Toshiba was selling CT machines with Windows 2000 on it because either A) the government hadn't updated their certs with regards to new windows versions, or Toshiba hadn't spent the money getting their software/hardware certed on the newer software.
And like phone manufacturers, even though their equipment will be in the field for many many years, they don't bother to update the base OS at all.
Right. It's archaic. Required and no way around it, but it doesn't make it not archaic and it also means that there is no supported option. Windows 2000 is out of support. So this takes the whole thing out of the supported world completely.
-
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
What @scottalanmiller said.
You have no advantages besides support from a vendor who only supports dedicated hardware. Which is just insane in most cases.
Unless you are that .0001% of cases where you can't virtualize, your software needs to be supported in a virtual environment.
-
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
And it's a waste for them to be virtualized.
-
@scottalanmiller said in Domain Controller Down (VM):
@Dashrender said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
Dedicating hardware to a single function is archaic.
No it's not.
The healthcare field has a handful of worthwhile usable applications, that only they know how to fix. If you're running on something using PV drivers that they don't understand, you're not going to get support, which you will probably need.
And... that's archaic. It's not that bad, incapable vendors don't require this. It's that that is archaic. Dedicated hardware is not the issue, but most healthcare software is downright embarassing and decades out of good practice and poorly supported or outright unsupported by the vendors.
Yep, they are both - super cheap on spending resources to keep their software up to date with modern design, and the government not certifying new OSs/software for medical use.
Example, Toshiba was selling CT machines with Windows 2000 on it because either A) the government hadn't updated their certs with regards to new windows versions, or Toshiba hadn't spent the money getting their software/hardware certed on the newer software.
And like phone manufacturers, even though their equipment will be in the field for many many years, they don't bother to update the base OS at all.
Right. It's archaic. Required and no way around it, but it doesn't make it not archaic and it also means that there is no supported option. Windows 2000 is out of support. So this takes the whole thing out of the supported world completely.
Supported from MS, sure, but not support from Toshiba.
-
@DustinB3403 said in Domain Controller Down (VM):
Unless you are that .0001% of cases where you can't virtualize, your software needs to be supported in a virtual environment.
Only if you care about having good, supported, above the home line systems. If you are just out to make money, good support isn't required.
-
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
And it's a waste for them to be virtualized.
Wasted how so? Higher reliability and availability, with support from companies who understand modern technology...
-
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
-
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
And it's a waste for them to be virtualized.
What? Virtualization is an "always" for really important reasons. Safer, more reliable, better support, better stability, fewer caveats, better support options, lower cost for both parties, more flexibility... all things that are pretty important for production systems.
-
@stacksofplates said in Domain Controller Down (VM):
No one can support every hypervisor at that level.
Don't need to. They don't support every OS at that level either, right? You support at least one. That you can't support "all" doesn't matter. They lack ANY production deployment scenario at this point. Not just limited ones.
-
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@DustinB3403 said in Domain Controller Down (VM):
what advantages do you get from dedicated hardware that aren't present with a virtual environment
Storage, compute nodes, RDMA, etc
I get all of those with virtual.
And it's a waste for them to be virtualized.
What? Virtualization is an "always" for really important reasons. Safer, more reliable, better support, better stability, fewer caveats, better support options, lower cost for both parties, more flexibility... all things that are pretty important for production systems.
No it's not. It makes no sense to virtualize a system like that when at bare metal you're pegging the system at 100%. I can re-kickstart the system in the same amount of time it takes to copy the image back onto the hypervisor.
-
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
Build your own qcow2 image, this way you can set the options specific to the software you plan to run.
Your argument here is "no one can support all of the settings" but if you have a qcow2 image, presumably it's coming from the vendor in a configuration that is supported / supportable.
Why else would they release it...
-
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
No one can support every hypervisor at that level.
Don't need to. They don't support every OS at that level either, right? You support at least one. That you can't support "all" doesn't matter. They lack ANY production deployment scenario at this point. Not just limited ones.
Hold the phone - this whole thing started because Dustin says that no vendor should be able to demand what hypervisor you can or can't use. (FYI - I don't agree with Dustin, it's just where this started).
-
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
Also, none of those things need to be supported by the app vendor. They just need to support the app and stop looking for meaningless excuses to block support. I understand some vendors want to support all the way down the stack, but if they don't know how to do that with virtualization, they don't know how to do it. The skills to support the stack would give them the skills to do it virtually even better (fewer variables.) So that logic doesn't hold up.
-
@DustinB3403 said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
Build your own qcow2 image, this way you can set the options specific to the software you plan to run.
Your argument here is "no one can support all of the settings" but if you have a qcow2 image, presumably it's coming from the vendor in a configuration that is supported / supportable.
Why else would they release it...
Yes that's what I'm saying. A qcow2 image you set up.
-
@Dashrender said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
No one can support every hypervisor at that level.
Don't need to. They don't support every OS at that level either, right? You support at least one. That you can't support "all" doesn't matter. They lack ANY production deployment scenario at this point. Not just limited ones.
Hold the phone - this whole thing started because Dustin says that no vendor should be able to demand what hypervisor you can or can't use. (FYI - I don't agree with Dustin, it's just where this started).
I never saw that, only that they don't support any production deployment (virtualization) whatsoever.
-
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
Also, none of those things need to be supported by the app vendor. They just need to support the app and stop looking for meaningless excuses to block support. I understand some vendors want to support all the way down the stack, but if they don't know how to do that with virtualization, they don't know how to do it. The skills to support the stack would give them the skills to do it virtually even better (fewer variables.) So that logic doesn't hold up.
You still haven't provided a single healthcare vendor that does any of what you say is appropriate.
-
@scottalanmiller said in Domain Controller Down (VM):
@Dashrender said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
No one can support every hypervisor at that level.
Don't need to. They don't support every OS at that level either, right? You support at least one. That you can't support "all" doesn't matter. They lack ANY production deployment scenario at this point. Not just limited ones.
Hold the phone - this whole thing started because Dustin says that no vendor should be able to demand what hypervisor you can or can't use. (FYI - I don't agree with Dustin, it's just where this started).
I never saw that, only that they don't support any production deployment (virtualization) whatsoever.
No, it was that they only supported VMware.
-
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
@scottalanmiller said in Domain Controller Down (VM):
@stacksofplates said in Domain Controller Down (VM):
If you're running on something using PV drivers that they don't understand...
Then your critical app vendor is below the home line. THAT'S how scary this should be to companies.
When your "business critical support" lacks the knowledge and skills of your first year help desk people, you need to be worried about their ability to support. Sure, when nothing goes wrong, everything is fine. But if anything goes wrong, you are suggesting these people don't have even the most rudimentary knowledge of systems today. That's worrisome. And it's why so many systems simply have no support options - relying on software and hardware that is out of support meaning that while the app might call itself supported, they depend on non-production systems making the whole thing out of support by extension.
So when running with a preallocated qcow2 image, which caching mode do you use for your disk? Writethrough, writeback, directsync, none?
What about IO mode? native, threads, default?
No one can support every hypervisor at that level.
Also, none of those things need to be supported by the app vendor. They just need to support the app and stop looking for meaningless excuses to block support. I understand some vendors want to support all the way down the stack, but if they don't know how to do that with virtualization, they don't know how to do it. The skills to support the stack would give them the skills to do it virtually even better (fewer variables.) So that logic doesn't hold up.
You still haven't provided a single healthcare vendor that does any of what you say is appropriate.
We don't work in healthcare, so why would we know the vendors. The point is that software should be supportable in it's environment (hypervisor agnostic)
