Consolidating several business servers onto fewer physical machines can make administration more manageable. It can also bring previously separate services into the same failure domain. If accounting, authentication and file access all depend on one host, that host’s maintenance window becomes a business event rather than a routine hardware task.
Virtualisation failure domain planning asks what can fail together and what remains available afterwards. Capacity planning asks whether the surviving environment can perform the required work. These questions belong in the same discussion because spare processing capacity is not useful when the storage, network or credentials needed to use it are unavailable.
A useful design begins with services and evidence. It does not begin with a target number of virtual machines per host. The following planning approach is platform-neutral; supported configurations, resilience features and licensing need confirmation for the selected hypervisor, hardware and software versions.
Describe business services before counting virtual machines
A virtual machine inventory is necessary, but it is not a complete service map. One application may depend on a database, identity service, file location and scheduled integration running on different machines. Conversely, a single server may support several departments without those dependencies being documented.
For each business service, identify its owner, normal operating hours and critical activities. Ask what staff can do if the service is unavailable. A temporary manual procedure may be realistic for one workflow and impossible for another.
Record dependencies in the order needed for recovery. If an application requires authentication and name resolution before it will start correctly, those supporting services need attention first. Include external dependencies, such as a hosted application or internet connection, even when they are outside the virtualisation project.
Use the map to decide which services must remain separated. Two servers described as redundant provide limited reassurance if they share every important physical dependency. The design should explain the failure it is intended to tolerate, not merely display duplicate boxes.
Measure demand across an actual business cycle
A brief utilisation snapshot can hide the periods that determine capacity. Observe ordinary working hours, scheduled reports, backup activity, batch processing and other predictable peaks. Ask department owners about month-end or seasonal work that may not appear during the initial measurement period.
Review CPU, memory, storage performance and network demand together. A workload with modest processor usage can still be sensitive to storage delays. A large memory allocation may reflect an old configuration choice rather than a measured requirement, so distinguish allocation from observed use.
Keep the measurement method and timeframe in the assessment. A number without context can be misused later as proof that substantial spare capacity exists. Record unusual conditions, such as a department being closed or an overnight process failing to run.
Document growth assumptions separately from current demand. New applications, increased document volumes and additional users should not be blended into an unexplained safety margin. A visible assumption can be challenged and updated when business plans change.
Evaluate the environment after a failure
Normal operation is only one capacity scenario. Model the loss of a host and determine which workloads should continue, which may restart and which can be deferred. The answer should be a service priority agreed with the business, not the order in which virtual machines happen to appear in a console.
Calculate whether surviving resources can support that priority set. Include the overhead and contention associated with recovery activity. Restoring or restarting several workloads can create a different demand pattern from steady operation.
Do not assume that an idle host solves every problem. Check whether it can reach the required storage and networks, whether its configuration is compatible and whether administrators can operate it without depending on a failed management component.
Where the design cannot maintain all services after a failure, state that limitation clearly. A documented reduced-service mode may be acceptable. An unstated expectation that every application will run normally is a source of avoidable conflict during an incident.
Trace shared dependencies beyond the host
Create a failure-domain register covering physical hosts, storage systems, switches, power sources, cooling and management services. For each item, identify the services that could be affected and the intended recovery response. This often reveals dependencies that are absent from the virtual machine inventory.
Consider physical location. Equipment in different cabinets may still share the same electrical supply or room conditions. Different network links may converge on one switch. Independence should be demonstrated through the actual arrangement rather than inferred from the number of components purchased.
Storage deserves particular attention because many workloads may rely on it simultaneously. Ask what happens if the storage system becomes unavailable, if a path fails or if capacity is exhausted. The relevant answer depends on the deployed architecture and must be validated for that architecture.
Include the backup environment in this review. If backup management, recovery copies and production workloads all rely on the same unavailable infrastructure, recovery may require additional steps or equipment. Identify those requirements before consolidation removes the older physical servers.
Treat maintenance as a planned resilience exercise
Maintenance exposes many of the same dependencies as an unexpected failure, but with more preparation time. Decide how a host will be taken out of service for updates, hardware work or investigation. Confirm which workloads can move or stop under the selected platform’s supported procedures.
Set a maintenance acceptance criterion in business terms. For example, the accounts team may need to complete a defined test transaction after its service is returned. A host reporting healthy does not establish that every dependent application is functioning.
Document a rollback decision point. If the work takes longer than expected or a workload behaves unexpectedly, the team needs a clear choice between continuing, restoring the previous state and invoking the service fallback.
Use lessons from maintenance to improve the failure plan. Unexpected credential dependencies, missing installation media and inaccurate network records are valuable findings when discovered during a controlled window rather than during a wider outage.
Separate restart, recovery and data protection
Restarting a virtual machine elsewhere is not the same as recovering an earlier trustworthy version of its data. The business may need both capabilities. Explain what each part of the design addresses so that resilience features are not mistaken for protection against every kind of incident.
Define recovery point and recovery time objectives for important services. The first concerns acceptable data loss; the second concerns the interruption before useful work resumes. Agree how those objectives will be measured and who will validate them.
Test a recovery route that does not assume the primary host remains available. Include the required credentials, encryption information, destination capacity and application knowledge. A technically readable backup still needs a practical path back to an operational service.
If the project needs independent assessment of these dependencies, Maxicon’s IT services offer a relevant route for discussing the existing environment and the intended consolidation outcome.
Make the commercial comparison reflect operating reality
Compare proposals using the same service assumptions. One design may include capacity for a host outage while another only covers normal demand. Comparing their purchase totals without identifying that difference can make the less resilient design appear equivalent.
Include implementation, migration, support, backup, monitoring and the resources needed for testing. Confirm licensing with the relevant suppliers against the actual products and deployment model. Avoid extrapolating from a previous project whose workload or entitlement assumptions were different.
Consider the skills available after handover. A design that depends on specialist procedures should include documentation and an achievable support route. The business needs to know who can diagnose an incident when the original implementation engineer is unavailable.
Record expansion triggers. Instead of waiting for a general complaint that the system is slow, define which sustained measurements or planned business changes will prompt a capacity review. This makes future investment easier to justify with evidence.
Run a pilot that can challenge the design
Choose a representative workload with an accountable owner and a recoverable migration path. Verify baseline performance before moving it, then repeat the same business activities afterwards. Include integrations, scheduled tasks and access from ordinary user devices.
Exercise the planned maintenance and recovery procedures within an approved scope. Record what actually happened, including manual interventions. A pilot that only proves the application starts does not test the assumptions behind the resilience design.
Keep an issue register with severity, owner and closure evidence. Resolve important findings before adding more workloads. If a design assumption changes, revisit the capacity and failure-domain assessment rather than treating the change as an isolated technical detail.
At handover, provide an updated service map, host inventory, recovery priorities, operating procedures and test results. Contact Maxicon with these requirements or an existing infrastructure inventory to discuss a virtualisation plan grounded in how your business needs to operate.
Frequently asked questions
How many virtual machines should run on one host?
There is no useful universal number. Workload behaviour, resource requirements, growth, recovery priorities and the host configuration all matter. Assess measured demand and the capacity needed during maintenance or failure. A small number of demanding workloads can require more planning than a larger group of lightly used servers.
Does having two hosts guarantee availability?
No. The hosts may share storage, network equipment, power or management dependencies. The platform must also be configured and licensed for the intended behaviour. Identify the specific failure being addressed, verify the surviving resources and test the resulting service experience before describing the arrangement as meeting an availability requirement.
Should capacity be based on average utilisation?
Averages help describe general demand but can conceal short periods of contention and business-critical peaks. Review the relevant operating cycle and the interaction between workloads. Capacity decisions should account for important peak activity and degraded operation, with documented assumptions about growth and which services may be deferred.
Can virtual machine resilience replace backup?
No. Keeping a workload running or restarting it after infrastructure failure does not necessarily recover deleted, corrupted or unwanted data. Plan the recovery history and independent copies required by your incident scenarios. Test both service continuity and restoration of usable information because they demonstrate different parts of the overall design.
What should be included in the final handover?
Include the service dependency map, resource assumptions, configuration records, recovery order, support contacts and results of agreed tests. Identify unresolved limitations and the person responsible for each follow-up. The handover should allow another authorised administrator to understand the environment and support an incident without reconstructing the original design decisions from memory.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s managed IT services in Karachi.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
