Virtualization when there is only one VM?
-
@DustinB3403 said in Virtualization when there is only one VM?:
@IRJ said in Virtualization when there is only one VM?:
I mean if you are talking about one server, I would just throw it on the cloud, schedule snapshots, sync file level backups with s3/blob storage and call it a day.
This is true, but it's still virtual. He's asking why would you virtualize just a single server (on premise) if that is all that would be on that host.
The OP is just confusing to me. Why would be want to buy a dedicated server to run one VM?
I am wondering if he is considering running it using desktop hardware which is even worse lol.
-
I generally see no benefit from choosing not to virtualize. Perhaps one could make the argument that you're adding a bit of administrative overhead for "just one VM." I find such overhead to be insignificant.
-
@IRJ said in Virtualization when there is only one VM?:
@DustinB3403 said in Virtualization when there is only one VM?:
@IRJ said in Virtualization when there is only one VM?:
I mean if you are talking about one server, I would just throw it on the cloud, schedule snapshots, sync file level backups with s3/blob storage and call it a day.
This is true, but it's still virtual. He's asking why would you virtualize just a single server (on premise) if that is all that would be on that host.
The OP is just confusing to me. Why would be want to buy a dedicated server to run one VM?
I am wondering if he is considering running it using desktop hardware which is even worse lol.
Anything is possible. He could have the hardware around and just wants to re-purpose it. But none of the "details" matters to the question.
You'd always virtualize first for all of the same reasons that virtualization exists today, and only if you hit some "oh yeah I can't because X" would you then consider the alternative physical approach.
From simple things like having to worry about a disk in an array going, you'd just move the VM if a resilver went sideways. Just an example.
All sorts of benefits and no negatives.
-
You could also have a rather massive VM that is near the capacity of your server, which you would still virtualize because of the same benefits of virtualizing.
Imagine having a VM with TB's of RAM and Petabytes of storage (very likely at or near exceeding what you could fit into a single server).
You'd virtualize that so you'd get all of the benefits, backup, recovery, migration etc.
Where as if that system were physical, you'd still have to contend with all of the administrative processes involved, but have none of the benefits of virtualization.
-
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
-
@Fredtx said in Virtualization when there is only one VM?:
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
You'd still virtualize, the administrative process is no different from the VM perspective compared to a physical install. Use RDP or whatever remote administrative tool you needed.
-
@Fredtx said in Virtualization when there is only one VM?:
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
Always virtualize.
I see no reason they need to login to their hypervisor or DB. I could see opening up RDP to allow them to issue reboot or something. I would want them to be familiar with SQL Management Studio at all, though. lol
-
@DustinB3403 said in Virtualization when there is only one VM?:
@Fredtx said in Virtualization when there is only one VM?:
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
You'd still virtualize, the administrative process is no different from the VM perspective compared to a physical install. Use RDP or whatever remote administrative tool you needed.
The problem @Fredtx is more likely to run into is small offices that are USING the server as a workstation as well as the server. Hyper-V and ESXi don't allow for local access to the VMs via GUI (that I know of). I think you can get there with KVM, as long as the management OS of KVM has a GUI on it. Not sure about anything else.
All that said - forcing the server to become more or less headless is a good thing in my mind. As Dustin mentions - using RDP or ScreenConnect or MeshCentral to manage the server remotely is likely the best option.
-
Yes, adding RDP would be the way to go. There will be additional overheard and point of failures on how to login their OS such as RDP not working, the server not being on the network, or the workstation they use to access to the server via RDP not being on the network (unless you put RDP on all workstations). On a physical server point of failures would be be if their monitor or peripheral are not working. Just looking at the pros and cons here.
-
RDP is a protocol, one that every system offers at a free level. Turning it on, and using it for solely administrative purposes (from an MS) perspective is without a doubt fine*.
As @Dashrender mentioned, trying to use the server console as a desktop would be a no-go (unless licensed). But the overall functionality and access portions are easy to setup and maintain.
-
@Fredtx said in Virtualization when there is only one VM?:
Yes, adding RDP would be the way to go. There will be additional overheard and point of failures on how to login their OS such as RDP not working, the server not being on the network, or the workstation they use to access to the server via RDP not being on the network (unless you put RDP on all workstations). On a physical server point of failures would be be if their monitor or peripheral are not working. Just looking at the pros and cons here.
If it's off the network - you have bigger issues - and you'll likely be able to use the console to resolve them, but I would expect the DDS to do that - they'd call you in for that.
-
Understood. These are the type of customers I see quite a bit. One's where the doctor has an on-premise physical server and had done that for years, even back in the 80's. I was looking at it from a different point of view if I was an IT consultant, would it be a good idea to implement virtualization for these type of customers with only 1 server in small practices. Or would it come around and bite me in the tail when they start having issues just logging in their server. They'll of course blame me and say, "This was never a problem before".
-
Are you introducing a new complexity? of course, does it have value? Yes it does. Does the value outweigh the complexity? That's a case by case situation.
If the customer is more apt to want to be involved in the repair situation, then having it virtualized will likely be very problematic, and you'll likely end up not going that route.
I have a customer that moved from a non-virtualized server to a virtualized one - and in my case the customer NEVER looks at the server. That's 100% my domain. So in their case, doing virtualization was easy with no drawbacks.
-
another advantage to being virtualized is remote access to the boot level of the VM. If you don't have iLo or iDrac on the server, you can't see the host system bootup, but with a hypervisor, that's rarely where the problem is. By virtualizing, you gain access to the boot level of the VM without the expense of iLo.
-
@JasGot said in Virtualization when there is only one VM?:
As I understand it, one might choose to visualize their server OS even if it is going to be the only OS running on the hardware.
Absolutely. Consolidation is in no way the primary reason for "always virtualize", so lacking consolidation should not alter the decision.
https://smbitjournal.com/2015/04/virtualizing-even-a-single-server/
-
@IRJ said in Virtualization when there is only one VM?:
The OP is just confusing to me. Why would be want to buy a dedicated server to run one VM?
This is extremely common in the SMB. We do it all of the time.
-
@IRJ said in Virtualization when there is only one VM?:
I mean if you are talking about one server, I would just throw it on the cloud, schedule snapshots, sync file level backups with s3/blob storage and call it a day.
Yeah, but we are talking real world. Not theory. Hosted (not cloud) isn't applicable to a giant percentage of actual companies. And building a cloud for a single VM would be even more work and zero benefit.
-
@Fredtx said in Virtualization when there is only one VM?:
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
We do this specific case almost daily. Depending on the hypervisor, there is no training whatsoever. And depending on how they access traditionally, there might be zero training. Anyone using a server properly will never know the difference.
-
@scottalanmiller said in Virtualization when there is only one VM?:
@IRJ said in Virtualization when there is only one VM?:
I mean if you are talking about one server, I would just throw it on the cloud, schedule snapshots, sync file level backups with s3/blob storage and call it a day.
Yeah, but we are talking real world. Not theory. Hosted (not cloud) isn't applicable to a giant percentage of actual companies. And building a cloud for a single VM would be even more work and zero benefit.
I'm sure he really meant - throw it in a VPS in something like Azure/AWS (assuming Windows) or Vultr (assuming non Windows).
-
@Dashrender said in Virtualization when there is only one VM?:
@DustinB3403 said in Virtualization when there is only one VM?:
@Fredtx said in Virtualization when there is only one VM?:
Although I don't disagree with choosing virtualization over physical install, but what about small Dental or Medical practices who have a local DB where their practice management software resides? I'm guessing clients like that would just require additional training on how to login their hypervisor and into their vm? There's cases where they need to remote software support in their DB for software related issues?
You'd still virtualize, the administrative process is no different from the VM perspective compared to a physical install. Use RDP or whatever remote administrative tool you needed.
The problem @Fredtx is more likely to run into is small offices that are USING the server as a workstation as well as the server. Hyper-V and ESXi don't allow for local access to the VMs via GUI (that I know of). I think you can get there with KVM, as long as the management OS of KVM has a GUI on it. Not sure about anything else.
All that said - forcing the server to become more or less headless is a good thing in my mind. As Dustin mentions - using RDP or ScreenConnect or MeshCentral to manage the server remotely is likely the best option.
Yup, we get this problem, a lot, in medical.
