New VM on VMWare ESXi 4.1 host
I just received a new Dell PowerEdge R710 with 1 processor, 1 TB RAID 5 w/ hot spare, and 9 GB of memory. I installed ESXi 4.1 with the intention of setting up one new VM with Server 2003, and converting two other physical Server 2003 machines.
I'd like the new VM to be a new domain controller for my network and possibly a file server, so I set it up with 2 processors, 2 GB of memory, and a 120 GB thick provisioned hard disk. I divided the HDD into two partitions - C with 40 GB and D with 80 GB for future data.
My question is did I setup the hard disk correctly? I see the downside is that I created a vmdk file of 120 GB, so copying this off as a backup is not very practical. But, I do have Acronis True Image 9 I can use to make an image of the server, so not sure if this is a big deal. Should I redo this with a single 40 GB partition and then add another disk for the data partition after the fact? Should I make the system partition thick and the data thin? Just not sure if any of this is a big deal, but this is my first experience with VMware and I would like to get things set up correctly!
Also - should I take any other special precautions with backup and recovery? I expect to keep this pretty small with 3-5 VM's running on the host.
I'd like the new VM to be a new domain controller for my network and possibly a file server, so I set it up with 2 processors, 2 GB of memory, and a 120 GB thick provisioned hard disk. I divided the HDD into two partitions - C with 40 GB and D with 80 GB for future data.
My question is did I setup the hard disk correctly? I see the downside is that I created a vmdk file of 120 GB, so copying this off as a backup is not very practical. But, I do have Acronis True Image 9 I can use to make an image of the server, so not sure if this is a big deal. Should I redo this with a single 40 GB partition and then add another disk for the data partition after the fact? Should I make the system partition thick and the data thin? Just not sure if any of this is a big deal, but this is my first experience with VMware and I would like to get things set up correctly!
Also - should I take any other special precautions with backup and recovery? I expect to keep this pretty small with 3-5 VM's running on the host.
either thin or thick works for you.
the advantage of thin is you can over commit as long as the disks in all the VMs are not all used. But if they do, then you may get in trouble.
I usually use thin and keep an eye on it. You can also setup alert to warn you.
the advantage of thin is you can over commit as long as the disks in all the VMs are not all used. But if they do, then you may get in trouble.
I usually use thin and keep an eye on it. You can also setup alert to warn you.
Personally, I would start small, and grow..........to meet future requirments.
It depends on what backup technology you are using, some do not backup "blank unsused space".
It depends on what backup technology you are using, some do not backup "blank unsused space".
BTW...it's best practice to have system volume on a separate virtual disk than data volume (virutal disk/vmdk).
~coolsport00
~coolsport00
have a read of this pdf on thick and thin...
http://www.vmware.com/files/pdf/VMware-vStorage-Thin-Provisioning-DS-EN.pdf
http://www.vmware.com/files/pdf/VMware-vStorage-Thin-Provisioning-DS-EN.pdf
ASKER
So best practice would be to create a new VM for Server 2003 with a 20-40 GB drive and a single partition (C) and then add a second disk for data after it is all setup?
Thin provisioned disks:
- You cannot use Fault Tolerance with a VM that has thin provisioned disks.
- Thin Provisioning allocates the storage in the VMDK, but the storage isn't actually backed by physical disk unless the data in the Guest OS is written to disk.
- Running defrag utilities inside the Guest OS of a VM, on a disk that is thin provisioned, will cause your thin provisioned disk to eventually consume all of its provisioned space faster than it would otherwise (essentially turning it into a thick provisioned disk) due to the many writes they perform during their normal operation.
- You can change a thick provisioned disk (such as one "created" in the previous point) to a thin provisioned disk by using Storage vMotion ... this also will defrag the VMDK in the process.
- Thin provisioned disks are usually susceptible to fragmentation moreso than a thick provisioned one, but can be dealt with by doing a Storage vMotion to attempt to improve performance.
- Storage vMotioning, cloning, and snapshots of a thin provisioned disk are faster, as only the actual data is being copied.
- Zeroing out your thin provisioned VMDKs will cause them to consume all of their provisioned space (turning them into thick disks.)
- You can easily find yourself over-committing your storage if you do not closely monitor the disk usage of your thin provisioned disks. If it's not monitored properly, and you end up provisioning more storage than you have available, then it's very easy to run into a situation where one VMDK will end up consuming the rest of the space in its datastore.
- You cannot use Fault Tolerance with a VM that has thin provisioned disks.
- Thin Provisioning allocates the storage in the VMDK, but the storage isn't actually backed by physical disk unless the data in the Guest OS is written to disk.
- Running defrag utilities inside the Guest OS of a VM, on a disk that is thin provisioned, will cause your thin provisioned disk to eventually consume all of its provisioned space faster than it would otherwise (essentially turning it into a thick provisioned disk) due to the many writes they perform during their normal operation.
- You can change a thick provisioned disk (such as one "created" in the previous point) to a thin provisioned disk by using Storage vMotion ... this also will defrag the VMDK in the process.
- Thin provisioned disks are usually susceptible to fragmentation moreso than a thick provisioned one, but can be dealt with by doing a Storage vMotion to attempt to improve performance.
- Storage vMotioning, cloning, and snapshots of a thin provisioned disk are faster, as only the actual data is being copied.
- Zeroing out your thin provisioned VMDKs will cause them to consume all of their provisioned space (turning them into thick disks.)
- You can easily find yourself over-committing your storage if you do not closely monitor the disk usage of your thin provisioned disks. If it's not monitored properly, and you end up provisioning more storage than you have available, then it's very easy to run into a situation where one VMDK will end up consuming the rest of the space in its datastore.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks!
~coolsport00