One Virtual Disk Then Partition Or Two Virtual Disks

R

rosco

Gawd
Joined
Jun 22, 2000
Messages
722
I am using Hyper-V to install a couple Win2k12 guests.

I want a guest install to have say 100GB for the guest OS to use and 600GB for the guest to store SQL database/data. Should I create one 700GB virtual disk and then partition in the guest OS, or one 100GB virtual disk and one 600GB virtual disk and have the guest OS use them as separate disks?
 
Virtual discs. You want it as manageable as possible throughout your hypervisor/vsphere/vcenter. thats my opinion :)
 
Would you mind explaining how if I want to allocate 700GB total to one virtual machine it is more manageable to attach two virtual disks to it instead of just one and having it partition the disk?
 
rosco said:
Would you mind explaining how if I want to allocate 700GB total to one virtual machine it is more manageable to attach two virtual disks to it instead of just one and having it partition the disk?
Click to expand...

There are any number of ways;
You deployed the VM from template, the template is sized for guest OS size plus some relatively small amount. Data drives are added as needed.
You only backup your data drives rather than the whole VM. This could happen a lot with file servers where different drives serve different purposes and are on a different backup/retention schedule
Migrations of data to new OS/app/whatever. Rather than potentially having to duplicate TB & TB of data you can disconnect the drive(s) and reconnect it on the new VM.
You want to have different provisioning levels between your OS and data drives (i.e. thick vs thin).
Your data drives are on a totally different storage tier from your OS or other data drives.

There are probably a whole bunch of other good reasons that I am not even aware of.

If you only attach one drive then there's little reason to even partition it. You increase complexity by partitioning for no tangible gain.
 
Thuleman said:
There are any number of ways;
You deployed the VM from template, the template is sized for guest OS size plus some relatively small amount. Data drives are added as needed.
You only backup your data drives rather than the whole VM. This could happen a lot with file servers where different drives serve different purposes and are on a different backup/retention schedule
Migrations of data to new OS/app/whatever. Rather than potentially having to duplicate TB & TB of data you can disconnect the drive(s) and reconnect it on the new VM.
You want to have different provisioning levels between your OS and data drives (i.e. thick vs thin).
Your data drives are on a totally different storage tier from your OS or other data drives.

There are probably a whole bunch of other good reasons that I am not even aware of.

If you only attach one drive then there's little reason to even partition it. You increase complexity by partitioning for no tangible gain.
Click to expand...

+1 use two disks
 
Easier to resize
easier to manage
easier to standardize.
etc etc etc
 
OK, it sounds like I will put everything for both virtual machines on the RAID10 array as follows:

VM1 (LOB Program)
1 150GB virtual disk

VM2 (SQL Database)
1 100GB virtual disk for OS
1 600GB virtual disk for SQL database
 
rosco said:
VM2 (SQL Database)
1 100GB virtual disk for OS
1 600GB virtual disk for SQL database
Click to expand...

I just checked an SQL 2012 server we are running on Win2012 and it's using 24.5 GB between the OS and the SQL server (but we don't have tempdb and logs on that drive, see below). Unless you plan to store a bunch of other stuff on your OS disk it probably doesn't need to be 100 GB, 50 will do to leave you enough room to stage updates etc.

Depending on performance considerations and whether you do have the option to put disks on faster than the Raid10 you were talking about; often the SQL tempdb and log files are put on a drive different from the actual database files. If you have a lot of transactions per second (I know that 'a lot' is relative) then it's definitely better for performance to separate the database from tempdb and logs.
 
Thuleman said:
I just checked an SQL 2012 server we are running on Win2012 and it's using 24.5 GB between the OS and the SQL server (but we don't have tempdb and logs on that drive, see below). Unless you plan to store a bunch of other stuff on your OS disk it probably doesn't need to be 100 GB, 50 will do to leave you enough room to stage updates etc.

Depending on performance considerations and whether you do have the option to put disks on faster than the Raid10 you were talking about; often the SQL tempdb and log files are put on a drive different from the actual database files. If you have a lot of transactions per second (I know that 'a lot' is relative) then it's definitely better for performance to separate the database from tempdb and logs.
Click to expand...

Exactly. That is what I stated in his other thread. Thuleman is correct about the Tempdb. It is all relative though. We have some SQL server that runs the tempdb on the same drives as the main DBs and other where they are separated. All depends on the workloads that the servers will see.
 
Thuleman said:
I just checked an SQL 2012 server we are running on Win2012 and it's using 24.5 GB between the OS and the SQL server (but we don't have tempdb and logs on that drive, see below). Unless you plan to store a bunch of other stuff on your OS disk it probably doesn't need to be 100 GB, 50 will do to leave you enough room to stage updates etc.

Depending on performance considerations and whether you do have the option to put disks on faster than the Raid10 you were talking about; often the SQL tempdb and log files are put on a drive different from the actual database files. If you have a lot of transactions per second (I know that 'a lot' is relative) then it's definitely better for performance to separate the database from tempdb and logs.
Click to expand...
If you have "space happy" people you can always do some thin C: drives to prevent them from sucking up host space for no reason.
 
You must log in or register to reply here.
Back
Top