What's the best way to create the smallest Server 2008 footprint in terms of Memory, and storage? I'm going to start with the Server 2008 Core version, but are there other known tools for ripping out pieces of the OS to reduce the size? I remember there being tools for XP such as BartPE. Is there an equivalent for Server 2008 or is the Core install the best I'm going to get?
question Smallest Server 2008 footprint
- Thread starter Handruin
- Start date
Chewy509
Wotty wot wot.
AFAIK, Core is it.
There may be some things to remove from Core, (some of the tools), but I wouldn't advise it.
There may be some things to remove from Core, (some of the tools), but I wouldn't advise it.
Mercutio
Fatwah on Western Digital
Yup. You can have Core if you don't need all that fancy GUI stuff. There's nothing like TinyXP for Server 2008.
Thanks for confirming my suspicion that there is no tool to make it smaller. I need to deploy 300 to 500 server 2008 machines and I need them as trim as possible. I'm hoping the minimum requirement of 512MB RAM for 2008 is less when using Core, but I'm not holding my breath.
Last edited:
250GB of RAM and a few TB of disk? Nice.
I'm hoping it won't actually consume 250GB of RAM. ESX has the transparent page sharing feature which I'm hoping with 300+ identical VMs that a lot of the memory address space is covered under this.
timwhit
0
What are these VMs going to be used for?
We need to test the scalability of our software. The software is used in large customer environments for host discovery and reporting. We will need to discover hosts through WMI and also WS-MAN, so we will try at different levels and try to extrapolate some of the scaling numbers. Server 2008 and Server 2008 Core are on our support matrix, so that's why I'm picking this one.
CougTek
Hairy Aussie
In a real environment, the 500VMs wouldn't be identical. The customers would use them differently and would tax them in different ways. Is it possible for you to copy real, in-use, VM from customers' backups? Have you deployed Win2008 core in VM used by your customers?
Correct, they would not all be identical in the real word, but that's OK for what we're trying to prove. We have ways to vary the latency in their response to our WMI and MS-MAN queries, so we can vary our own load if when needed. We've already established that WMI doesn't handle latency very well and is a chatty bastard. We're implementing functionality to solve that by using WS-MAN as an alternative if customers want to use it.
We rarely have the option from customers for them to give us a working copy of their system. Many are banks and financial institutions that won't even let us webex or remote desktop to their systems (with very good reason). Even in times when we visit on-site, we can't take cellphones or electronics into their buildings.
No, we've not deployed a Win 2008 Core VM used by our customers. We're mainly trying to answer if our own software can handle the mass number of discoveries of these systems and extrapolate some numbers. This tests assumes they're all identical and can respond adequately and similarly. A customer's system would respond in different amounts of time as you've suggested, but that's not what we are testing for right now. If we can't handle the discovery in a system that does respond consistently, then we're not ready to handle the discovery in a system that varies its responses.
Bozo
0
500 virtual machines boggle my mind. Would that be for 500 different business?
Bozo
0
Pardon me for asking a bunch of dumb questions.
I can see having a rack full of virtual machines running a company, but what do you do for backup. Another rack of identical virtual machines in a different location? How would you keep them syncronized?
Do the people using these virtual machines connect to them with a dumb terminal?
Thanks :thumbleft:
I can see having a rack full of virtual machines running a company, but what do you do for backup. Another rack of identical virtual machines in a different location? How would you keep them syncronized?
Do the people using these virtual machines connect to them with a dumb terminal?
Thanks :thumbleft:
They aren't dumb questions. There are a lot of ways to backup that many virtual systems and in several cases it doesn't differ much from a physical machine. Some shops will use traditional backup software for their own protection. Other ways to backup VMs can be done using the VMWare consolidated backup software. This software works by connecting directly to the storage array from a separate host. Each VM is temporarily put into a snapshot mode and then the contents of the VMs are backed up to a separate location. Once the backup is complete, the snapshot is removed and it's like nothing ever happened to the VM. The backed up contents can then be analyzed by deduplication software to reduce a lot of space. From this point the backups can be transferred to tape of to a similar device like a clariion disk library (and disk-based tape drive emulator).
In the environments I work in that have a couple hundred VMs, most are connected to by using SSH (Linux), remote desktop console (windows) or in cases where we cannot get to them, the vCenter client tool provides a complete KVM connection to any VM under its management regardless of the OS. There is rarely ever a need to go into a lab to get to a system. Even to manage the physical hardware can be done through the intranet through Avocent or the built-in HP iLo management interface.
In the environments I work in that have a couple hundred VMs, most are connected to by using SSH (Linux), remote desktop console (windows) or in cases where we cannot get to them, the vCenter client tool provides a complete KVM connection to any VM under its management regardless of the OS. There is rarely ever a need to go into a lab to get to a system. Even to manage the physical hardware can be done through the intranet through Avocent or the built-in HP iLo management interface.
Bozo
0
Thanks! :smile:
I have an update on this. I've got a Server 2008 (64-bit) system up and running. It is running with one vCPU and 196MB of RAM. Task manager shows 67MB still available, so if I want to push my luck, I could probably drop it down a bit more.
The main hard drive is set to a thin-disk and is currently consuming 3.5GB of space for the install (the OS thinks it's a 40GB disk). I added eight additional drives at 10MB each for testing purposes. We just need to see multiple drive letters during WMI discovery, the actual space the drive contains does not matter for our test.
Soon we will be testing the configuration on this single machine and probably in a week or so we will be deploying 300 of these guys.
In raw numbers we're looking at:
58,800 MB RAM
300 vCPUs spread across 12 cores (25/core which is VMwares max)
1075GB disk space
The main hard drive is set to a thin-disk and is currently consuming 3.5GB of space for the install (the OS thinks it's a 40GB disk). I added eight additional drives at 10MB each for testing purposes. We just need to see multiple drive letters during WMI discovery, the actual space the drive contains does not matter for our test.
Soon we will be testing the configuration on this single machine and probably in a week or so we will be deploying 300 of these guys.
In raw numbers we're looking at:
58,800 MB RAM
300 vCPUs spread across 12 cores (25/core which is VMwares max)
1075GB disk space
Wow, that is really thin to simulate 300 machines. I love virtualization.
Medium update for anyone who is curious. Last night I was finally ready to deploy a small subset of machines based on the full goal of 300. I did a light test run with 64 W2K8 Core systems. There were some adjustments needed before we could deploy and it also took some time for IT to create the two new vlans we needed for the IP addresses for these machines.
Using powershell scripts and the vmware powershell framework, the scripting was able to deploy the 64 VMs in about 6 hours which we all ready and usable. This included the host customization setup which took care of the network configuration and naming, so there was no manual intervention needed which was extremely nice. After kicking off the script, the only thing I had to do was verify the systems came online and were accessible through the network. I put together a small tool for pinging a range of IPs so that the users of these VMs can verify if they are responding before running their tests.
One of the last minute changes I needed to do was to add our corporate antivirus (per policy). That of course is based on McAfee which isn't the most resource-friendly for a system like this (we're talking 45MB out of the 196MB allocated RAM!). I can't wait to see what happens when all 64 machines perform their nightly 3:00AM scan! That'll only get worse when there are 300.
The resource pool these are in is claiming about 13GB of used memory of which only 1 GB is shared (that's disappointing) and 1.7GB for VMware overhead. That shared number may increase once more constraint is felt with 300 machines. The average consumed MHz is only 404MHz which is decent. So far it has been a success.
Using powershell scripts and the vmware powershell framework, the scripting was able to deploy the 64 VMs in about 6 hours which we all ready and usable. This included the host customization setup which took care of the network configuration and naming, so there was no manual intervention needed which was extremely nice. After kicking off the script, the only thing I had to do was verify the systems came online and were accessible through the network. I put together a small tool for pinging a range of IPs so that the users of these VMs can verify if they are responding before running their tests.
One of the last minute changes I needed to do was to add our corporate antivirus (per policy). That of course is based on McAfee which isn't the most resource-friendly for a system like this (we're talking 45MB out of the 196MB allocated RAM!). I can't wait to see what happens when all 64 machines perform their nightly 3:00AM scan! That'll only get worse when there are 300.
The resource pool these are in is claiming about 13GB of used memory of which only 1 GB is shared (that's disappointing) and 1.7GB for VMware overhead. That shared number may increase once more constraint is felt with 300 machines. The average consumed MHz is only 404MHz which is decent. So far it has been a success.
Mercutio
Fatwah on Western Digital
I feel sorry for the storage pools that have 300 simultaneous virus scans. Your CPUs can take a pounding like that but that sounds like a great way to kill a mechanical drive or 10.
I agree. I already received a media warning from our clariion on one of the array disks. lol I'll let you know if I have to start replacing drives over the next few months of their operation.
I already had to delete the 64 machines and rebuild them. There was a problem with the template configuration that was discovered. Hopefully now it is configured correctly for our WMI and WSMAN discoveries.