Jamesm007
asked on
Server 2008 Hyper V disk setup
I am trying to get my head around the initial setup for Hyper V.
I have 2 mirrored 148GB SAS drives which I have partitioned using full size and installed Server 2008 STD and instaled the Hper V Service.
4 RAID drives that I intend to mirror Raid 10 and use as DATA drives.
I also want to add 2 more mirrored drives 146GB SAS and install SBS2008 Premium server on this.
The question is with the drives, such as data drive, so I need to partiton this using the Server 2008 Host so that the other VM servers can use it, or is it done in a different way?
Same with the 2 mirrored drives for SBS Premium, do I partition them and when I create the VM browse to that drive letter?
Is this the standard practise or is there another way to do this?
Note the data drive will be viewable mainly from the SBS 2008 Virtual server so do I add this from there instead?
Just need some clarity on this please.
thanks
I have 2 mirrored 148GB SAS drives which I have partitioned using full size and installed Server 2008 STD and instaled the Hper V Service.
4 RAID drives that I intend to mirror Raid 10 and use as DATA drives.
I also want to add 2 more mirrored drives 146GB SAS and install SBS2008 Premium server on this.
The question is with the drives, such as data drive, so I need to partiton this using the Server 2008 Host so that the other VM servers can use it, or is it done in a different way?
Same with the 2 mirrored drives for SBS Premium, do I partition them and when I create the VM browse to that drive letter?
Is this the standard practise or is there another way to do this?
Note the data drive will be viewable mainly from the SBS 2008 Virtual server so do I add this from there instead?
Just need some clarity on this please.
thanks
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.
You should not virtualize SBS 2008 as this is your primary domain controller and carries the FSMO roles.
If you do, then you will have a problem at startup since SBS is virtualized and starts up after the host and the servers cannot connect to the domain controller.
It is recommended that at least one domain controller is in a non virtualized environment AND not on a host for the virtual machines.
The host OS should be on one partition and the virtual machines should be on a separate.
If you do, then you will have a problem at startup since SBS is virtualized and starts up after the host and the servers cannot connect to the domain controller.
It is recommended that at least one domain controller is in a non virtualized environment AND not on a host for the virtual machines.
The host OS should be on one partition and the virtual machines should be on a separate.
My understanding is that the supported option with SBS is to run it and the 2nd OS as VMs on the host. My instinct is to not join the host to the domain and everything would be okay. It may actually be possible to join the host to the domain, but the domain will never be available during boot and that scares me.
It would be nice if Microsoft supported running SBS in the parent partition with the Hyper-V role, but they don't.
It would be nice if Microsoft supported running SBS in the parent partition with the Hyper-V role, but they don't.
They don't becasue it can cause instabillity of the shared resources since you cannot control how much resources are being used for the domain controller.
Also, you don't want to because the more roles and features you have running, the highter the chances are that you need to do some restarts on changes, and to do so, you have to power down all the vm's on the host.
Also, you don't want to because the more roles and features you have running, the highter the chances are that you need to do some restarts on changes, and to do so, you have to power down all the vm's on the host.
If you do virtualize SBS (or any PDC emulator DC), I recommend that you set the host system to synch with the authoritative time source (something like time.nist.gov). Then enable the Time synchronization integration component for the SBS guest OS. The host system will be able to keep time better than the guest os, since it is not affected by time virtualization.
There are some benifits to having time synchronization integration component in place, specifically when you are starting a VM from either an off state or from a snapshot (which you should NOT use for ANY DC). A VM starts up and doesnt have a hardware time clock to synch time from during the OS load. There are some mechinisms that are used by Hyper-V (under the hood) to get a somewhat accurate time, but it has a chance to be wrong occaisionaly. With the time synch integration component in place, time is synched with the host OS very soon after boot, and you dont have to worry about any time skew that might take place. Since the PDCe is the authoritative time source for the domain it is very important that time is correct on this server.
As far as installing any other roles or software in the parent partition (host OS)...
The reason why you would never want to use SBS as the host OS for Hyper-V is beacuse almost all (if not all) guest communication to the hardware runs through the parent partition. A slow down of the parent partition will slow down all of the guest operating systems that are running on the system.
SBS is a resource hog - since it is always running DC roles and possibly running exchange, SQL, IIS, Sharepoint, etc roles on it. On a perfectly running SBS system, there are times of hardware resouce contension - so adding more applications that need to access the system would just create a performance mess.
When I am making recommendations to customers, I recommend that the only thing running in the host OS are things like backup agents, or AV scanners (with the correct exclusions). You shouldnt run any other apps than are absolutely necessary. If there is a need to run a new app - create a new vm and run the app in the vm. This ensures (as much as you can) that the parent partition will run optimally and not cause slow downs for the guest operating systems.
Which domain should the host OS be a member of?...
This is a personal preference question. The host OS (HyperV system itself) can be a member of a domain where the only domain controller is virtualized. If you do this, you would need to make sure that the domain controller VM (SBS server in your case) is set to auto start immediately on boot. You also need to make sure that you can log on to the HyperV system with cached credentials (basically, dont mess with the default domain settings for this). Personally, I dont like this method.
I prefer to make the Hyper-V server either a member of a seperate management domain or a member of a workgroup. In your case, Im pretty sure that you would want to make it a member of a workgroup. This eliminates the need for the HyperV system to rely on a VM for domain related functions.
There are some benifits to having time synchronization integration component in place, specifically when you are starting a VM from either an off state or from a snapshot (which you should NOT use for ANY DC). A VM starts up and doesnt have a hardware time clock to synch time from during the OS load. There are some mechinisms that are used by Hyper-V (under the hood) to get a somewhat accurate time, but it has a chance to be wrong occaisionaly. With the time synch integration component in place, time is synched with the host OS very soon after boot, and you dont have to worry about any time skew that might take place. Since the PDCe is the authoritative time source for the domain it is very important that time is correct on this server.
As far as installing any other roles or software in the parent partition (host OS)...
The reason why you would never want to use SBS as the host OS for Hyper-V is beacuse almost all (if not all) guest communication to the hardware runs through the parent partition. A slow down of the parent partition will slow down all of the guest operating systems that are running on the system.
SBS is a resource hog - since it is always running DC roles and possibly running exchange, SQL, IIS, Sharepoint, etc roles on it. On a perfectly running SBS system, there are times of hardware resouce contension - so adding more applications that need to access the system would just create a performance mess.
When I am making recommendations to customers, I recommend that the only thing running in the host OS are things like backup agents, or AV scanners (with the correct exclusions). You shouldnt run any other apps than are absolutely necessary. If there is a need to run a new app - create a new vm and run the app in the vm. This ensures (as much as you can) that the parent partition will run optimally and not cause slow downs for the guest operating systems.
Which domain should the host OS be a member of?...
This is a personal preference question. The host OS (HyperV system itself) can be a member of a domain where the only domain controller is virtualized. If you do this, you would need to make sure that the domain controller VM (SBS server in your case) is set to auto start immediately on boot. You also need to make sure that you can log on to the HyperV system with cached credentials (basically, dont mess with the default domain settings for this). Personally, I dont like this method.
I prefer to make the Hyper-V server either a member of a seperate management domain or a member of a workgroup. In your case, Im pretty sure that you would want to make it a member of a workgroup. This eliminates the need for the HyperV system to rely on a VM for domain related functions.
ASKER
Thanks for the info, yes I was going to keep the host OS as part of a workgroup as I could not see the benefit of making it part of a domain that will not be available at bootup time.
The Host OS being on a different partition is understandable, but my question still remains, will I have an issue if I created several partitions on the same mirrored or raid 10 disc set and used them as the host OS and SBS install on different VDM's?
This is what I am trying to work out how to best setup the disk raids to reduce the risk of disk IO issues etc.
The Host OS being on a different partition is understandable, but my question still remains, will I have an issue if I created several partitions on the same mirrored or raid 10 disc set and used them as the host OS and SBS install on different VDM's?
This is what I am trying to work out how to best setup the disk raids to reduce the risk of disk IO issues etc.
Getting back to the point about disks, I would create a RAID set for the four 10K disks, and another RAID set for the 7.2K disks. I would use RAID 10 or RAID 5, depending and what your needs are for capacity vs IOPS. I would probably put the host on the 7.2K disk array because it doesn't really do any disk IO when running. When placing your VHD files, put them onto whichever disk set makes sense from a performance/capacity standpoint.
ASKER
By the way, SBS 2008 Premium comes with a license key to install SBS 2008 Virtual; 2008 SERVER STD Virtual and 2008 STD non vitual key.
I spoke to MS re this and they assured me that it would be OK to install SBS in this way before purchasing the licenses.
I spoke to MS re this and they assured me that it would be OK to install SBS in this way before purchasing the licenses.
If you have Hyper-V experience, I would install Hyper-V Server 2008 R2 on the host because the Hyper-V performance and management is better. downside is that it's Windows Core, so you need to do all management remotely from another workstation. It would be nice if microsoft included Windows 2008 R2 as part of the package, but they don't.
You can split up the arrays and partition them just about any way that you would like and place VHDs on them technically.
As far as performance goes, you will need to monitor the Hyper-V system to ensure that you are not exceeding the disk throughput of the system. As you put more vhds from different systems on the same physical disks, you will experience increased disk access latency. With 1 vhd on a physical set of disks you will have times when you will get sequential writes - with multiple vhds on a system, the opportunity for sequential writes goes down since there mulitple systems (VMs) trying to access the same physical resource.
Ideally, you would have the VHD files seperated - But it really comes down to what load you have on your system and what performance you need.
So - in order to give you a good recommendation, I would need to know what type of load you are going to be putting on the SBS VM. (and if you plan on creating any other VMs on the system)
How many users are going to access the server (what will be planned for next 3 years - or life of the hardware)?
What will the maximum size of their mailboxes be?
How much mail will be sent per day (in GB)?
How much file share space will you need?
Will SQL be installed and used on the system - and what size databases and # of transactions will you need to handle?
Will any other disk intensive applications be used on the system?
As far as performance goes, you will need to monitor the Hyper-V system to ensure that you are not exceeding the disk throughput of the system. As you put more vhds from different systems on the same physical disks, you will experience increased disk access latency. With 1 vhd on a physical set of disks you will have times when you will get sequential writes - with multiple vhds on a system, the opportunity for sequential writes goes down since there mulitple systems (VMs) trying to access the same physical resource.
Ideally, you would have the VHD files seperated - But it really comes down to what load you have on your system and what performance you need.
So - in order to give you a good recommendation, I would need to know what type of load you are going to be putting on the SBS VM. (and if you plan on creating any other VMs on the system)
How many users are going to access the server (what will be planned for next 3 years - or life of the hardware)?
What will the maximum size of their mailboxes be?
How much mail will be sent per day (in GB)?
How much file share space will you need?
Will SQL be installed and used on the system - and what size databases and # of transactions will you need to handle?
Will any other disk intensive applications be used on the system?
I agree with Kevin - 2008 R2 Hyper-v performs much better than 2008 and if possible running that will make some of the planning easier. For one, you can use dynamic VHD files instead of fixed vhds and not worry about performance with 2008 R2.
ASKER
thanks for the tips, i have plenty of grunt and HDD space compared to the current server. Took some advice from both of you.tanks agin
ASKER
Youre close with the drive configuration - we have
4 X 146GB SAS 10k
4 X 500GB SAS 7.2k
You are correct I am using the SBS 2008 Premium license which allows me to install Server 2008 Host for Hyper V. I then want to virtualise SBS 2008 and Server 2008 STD (2 servers in total virtualised).
I can change 2 of the 146GB SAS to 2 X500GB SAS if this is more suitable.
I understand what you are saying and this makes good sense as my concern was that the 146GB was a waste of space if all it will have on it is just the host OS.
thanks for your input