Re: Best practice on virtualizing SBS
- From: MijakiDK <MijakiDK@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 29 Dec 2007 13:29:01 -0800
Wow that was a lot, nothing short and sweet from you Gumby :-)
The x64 issue has to be dealt with on a later stage as the existing server
is x32 and budget does not allow for the purchase of new hardware before 2009
- I hope ;-)
We are a tiny company with 6 active users - 3 working outside the office on
PDA (sales) and dsl in the evening for mail. So the performance we have today
is very fine and bottlenecks are not on the server side - I expect a virtual
SBS will not be slower.
At the moment my SBS is running on 1GB of ram, the host box will get 3GB and
I expect to use 2GB for the SBS and dual nic of course.
And finally, getting past the hardship of updating hardware using a virtual
SBS is a very promissing concept.
Currently I'm having user data etc. on the D-drive of my SBS and AFAI
understood you would keep the D-drive in the VHD file?
"SuperGumby [SBS MVP]" wrote:
I can't go as far as saying this is anything formal 'best practice' but....
Host box should be x64. This is even more necessary as we move forward where
the host can be expected to be best implemented as Windows Server 2008 (CORE
only) with Hyper-V, I believe this will be x64 with VT only. Even staying at
a W2k3+VS200x you can _expect_ x64 on the host to offer best performance.
OK, VMWare Server will do x64 guest on x32, as long as it fully supports VT
(CPU, mobo, BIOS), but the x64 host can be _expected_ to handle it better.
I'm starting to think that for a decent implementation you also want dual or
better 'teamed' NICs on the host. There is some impact to network
performance in the VM imposed by the mere fact of virtualisation,
compensating for this by providing the best possible network performance on
the host sounds like a reasonable idea.
It is suggested that having multiple RAID arrays, dedicating arrays to the
VM and providing the arrays to the VM as 'direct' drives will provide best
performance. I do not disagree with this in this aspect but prefer that only
the VM be able to access the content of it's drives, I therefore sacrifice
some performance by running 'drives as files'.
AV on the host should be told to exclude the folder containing and VHD's
from scanning and if you do provide 'direct drives' to the VM I'd also
exclude those drives from scanning by the host.
I would disable Shadow Copies on the host partitions holding VHD's. SC's of
the VHD's will not be maintained anyway, due to size, but I don't want any
impact from the host 'inspecting' the partition to see if it can SC
anything.
"MijakiDK" <MijakiDK@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FBC63E68-4EE5-43C3-B62A-7A700C2F937D@xxxxxxxxxxxxxxxx
Hey there,
Any input on this?
Do I take an ordinary W2K3 server an load my SBS as a virtual on that or?
Do I "loose" my D-drive for data and map to the data in the future when I
have done the virtualisation? Thus only make a virtual server of my SBS
C-drive?
I haven't got a SAN or anything - I'm simply trying to get my 2 server
system down to 1 physical box.
My other server is a W2K3 for TS.
Happy new year
Kim
- Follow-Ups:
- Re: Best practice on virtualizing SBS
- From: SuperGumby [SBS MVP]
- Re: Best practice on virtualizing SBS
- References:
- Re: Best practice on virtualizing SBS
- From: SuperGumby [SBS MVP]
- Re: Best practice on virtualizing SBS
- Prev by Date: Re: Exchange Activesync and Internal / External Domain on SBS 2003
- Next by Date: Re: How to allow client to disable firewall on XP/sp2 machine
- Previous by thread: Re: Best practice on virtualizing SBS
- Next by thread: Re: Best practice on virtualizing SBS
- Index(es):
Relevant Pages
|
