Questions about licensing issues after converting physical SQL server to virtual
-
@dashrender said in Questions about licensing issues after converting physical SQL server to virtual:
That said, if disk performance is your issue, not processor, then perhaps backing up the DB, then wiping our the current config, setting up RAID 10 HDD or RAID 5 SSD on that box will give you what you need. We don't know what your current drive setup is (how many drives, what size, what spindle speed).
RAID 5, we can only hope that the server is at least 8 years old though, and really more like 15 still being on RAID 5 an all.
This server is an 8-bay chassis and currently has 4x 600GB 6Gbps SAS HDD's in RAID 5 on a PERC H710 Mini (embedded) controller.
I have thought of other strategies, but the only other one I would be comfortable with is to get some extra 600GB drives and swap them out with the old drives, put them in a RAID 10, then restore the old system from a backup (using SPX). This way, if there are any issues, I can just throw the old drives back in..
-
@dave247 waves
-
If you replaced all the drives, why not virtualize it at the same time? RAID 10 along with converting to a VM seems like a good plan. Converting allows you more recovery options with no penalties.
If you can swing for a good RAID card with some cache, you'll probably notice some real gains in IOPs.
-
@dashrender said in Questions about licensing issues after converting physical SQL server to virtual:
If you replaced all the drives, why not virtualize it at the same time? RAID 10 along with converting to a VM seems like a good plan. Converting allows you more recovery options with no penalties.
If you can swing for a good RAID card with some cache, you'll probably notice some real gains in IOPs.
Now I'm confused... I was initially talking about converting it to a vm and running it in our virtual environment (vSphere 6.5) with a 20TB SAN/storage controller, completely separate unit from the R320. The other option is to essentially swap the RAID 5 for RAID 10 and continue using it as a physical server. It's one or the other. I don't understand what you mean about switching the RAID 10 + converting to virtual, sorry.
Thanks for the help.
-
In today's world, you don't skip virtualization, unless you have a specific reason to skip it. So, if you are replacing the drives anyway - when you reinstall, start by installing a hypervisor - Hyper-V or KVM are both 100% free. You're running ESXi already, so if you have an open license for a third host (assuming you have an essentials package, you could use that license on this host). Then install your single VM on this rebuilt server.
-
@dashrender said in Questions about licensing issues after converting physical SQL server to virtual:
In today's world, you don't skip virtualization, unless you have a specific reason to skip it. So, if you are replacing the drives anyway - when you reinstall, start by installing a hypervisor - Hyper-V or KVM are both 100% free. You're running ESXi already, so if you have an open license for a third host (assuming you have an essentials package, you could use that license on this host). Then install your single VM on this rebuilt server.
Yeah, we have the essentials package and we already have three hosts. Like I said, I would love to just make this a virtual machine, but I want to make sure it will work without any issues.
-
What gives you reason to think it won't work? You already trust it with three other hosts.
Virtualization adds very little overhead.
-
@dashrender said in Questions about licensing issues after converting physical SQL server to virtual:
What gives you reason to think it won't work? You already trust it with three other hosts.
Virtualization adds very little overhead.
FFS.
He is not talking about the hardware. -
No he's talking about SQL in a VM - what makes you (the OP) worry about this? Why worry about SQL, but not whatever is running on your other three VM hosts?
-
@dashrender said in Questions about licensing issues after converting physical SQL server to virtual:
No he's talking about SQL in a VM - what makes you (the OP) worry about this? Why worry about SQL, but not whatever is running on your other three VM hosts?
I'm actually talking about the converted system. Converting physical to virtual presents potential issues. I think I'll restore to a test environment first..
-
@dave247 said in Questions about licensing issues after converting physical SQL server to virtual:
Hi. New here..
I have a Poweredge R320 running Server 2012 R2 Standard which is running Microsoft SQL Server 2008 R2 (64bit). This server has always been a bit slow with often very high disk I/O. Performance has gotten worse over time and I believe it's due to the fact that it's disks are in a RAID 5, and the SQL DB has gotten larger over the years/had more use, etc.
Anyway, I wish to virtualize this system because our storage controller is RAID 10 with much better IOPs. We have 3x ESXi hosts, each with dual sockets and better processors than the R320 server as well, but I'm really only looking to improve disk I/O. This server is running a single Xeon E5-2440 0 (6 cores) btw.
I want to convert this system from physical to virtual (using vCenter Converter) and verify that there are no issues before we pay more money for licensing, assuming we have to pay to change # of CPU and cores. If there is an issue, I can just revert and we won't be out $. I am just unclear on if SQL Server 2008 actually knows when there's a hardware change and if it will stop functioning or something, or if the system will continue on without any issues.
Thanks. Also, hi Scott.
When you use the converter, it creates a VM with the same hardware specs.
So the VM will have the same number of sockets and cores as the physical box. There is no licensing issue there.
You will have to reactivate Windows, but again, not a licensing issue, just an activation.
Prior to running the converter, run a backup and shut down the SQL services so that no database files are open just to be safe.
I have done it live with no issues, but the butt cheeks were clinched.
