Best Practices

overview the following recommendations are for creating virtual machines some involve the settings of the machine e g (ram allocation, nics, etc), while others pertain to configuration within the guest os following best practice guidelines can avoid potential issues and provide better performance import recommendations the following recommendations apply when importing existing vm's and when migrating from physical to virtual prior to exporting from other systems, uninstall all hypervisor guest applications (e g vmware guest agent, hyper v integration components, etc) these guest applications will serve no purpose when running in your tenant, thus wasting resources and potentially causing other adverse results remove any hardware specific drivers/software (for example bios update monitors, etc) prior to exporting a physical image prior to performing an export of the physical drives, uninstall hardware that will not exist in the virtual machine otherwise, keep hardware configuration as similar as possible (number and size of drives, number and type of cpu's, etc ) often, it is preferable to keep mac addresses from the previous machine the same on the new virtual machine, otherwise, a different mac address will detect as a new network device within the guest os and require reconfiguration of all guest network settings for a machine that was imported using auto import utilities, you are prompted with the choice to reserve the mac address or auto generate a new mac address for machines that are manually imported (e g vm shell created and drives imported,) the mac address can be noted from the existing machine and then manually entered when creating the new machine nic it's important to remember that two machines should never be running within the same network using the same mac address ram allocation the amount of ram to allocate to a vm is the amount needed to adequately run the workloads within the vm when a vm is powered on, ram is allocated to that vm out of an available pool of memory and cannot be allocated to other vms (regardless of activity within the guest os ) generally, a virtual machine can be given less ram than when run bare metal and in other virtual environments; ram that would typically be needed within the vm to accommodate disk performance functions, caching, etc is not needed because these functions are handled automatically by the vsan selecting cpu type a default cpu type is provided per cluster, based on the detected cpu type of the host hardware; this is typically the best option to select for each virtual machine if a virtual machine is imported and the cpu type is changing, windows license re activation/additional power cycles may be necessary if a machine might eventually be migrated/failed over to clusters with different host cpu hardware, select the lowest class of cpu chip type used among the clusters when creating the new vm this will ensure the machine can be ported to older chip classes without issue os family selecting the correct os family (e g windows/linux/freebsd) for the vm will help to ensure the correct qemu flags are used when starting the vm, which in turn can affect performance this is particularly important for windows based vms power saving all power saving features should be disabled within the guest os as these features will provide no benefit and most likely will cause problems select a performance profile rather than a power saving profile acpi without acpi support, it will be necessary to enter the guest operating system to carry out a clean shutdown of the vm; this is not optimal, particularly with a larger quantity of machines acpi should be enabled and configured within the guest operating system to allow for gracefully powering down a vm from the management interface (or via api) before putting a vm into production, it's recommended to test restart and power off operations from the dashboard, while the vm is at a login prompt/locked screen within the guest os, to verify acpi is configured correctly clock synchronization generally all vm servers, particularly those running time critical applications, should have ntp configured and installed within the guest os computers automatically sync with their hardware clock when power cycled and in between power cycles as controlled by their guest os; most often this alone is not frequent enough to keep a vm adequately synchronized ntp is intended to keep computers synchronized on a more frequent basis (to keep clock synchronization within a few milliseconds ) ntp servers should be chosen with care, with edge servers pointing to ntp sources known to be reliable and geographically appropriate as it's important for host nodes and guests to be in sync, guest machines should be configured to use their host nodes as ntp server or should be configured to use the same ntp servers as the physical host nodes utc/local time windows vms by default, the system provides the time to virtual machines in utc format windows, by default, expects to receive time in local time; therefore, for windows virtual machines, do one of the following configure vm settings to use local time select local time for the clock source in the vm settings (recommended) (recommended) configure windows to use utc make appropriate registry key changes within the windows vm to use utc format vm drives virtio drivers typically provide the best performance most versions of linux operating systems natively contain virtio drivers for windows machines, the latest virtio drivers can be downloaded https //fedorapeople org/groups/virt/virtio win/direct downloads/stable virtio/virtio win iso the system uses thin provisioning for virtual disks, therefore space allocated to virtual drives is not actually consumed on the vsan until it's consumed inside the guest os in many cases it may be preferable to allocate a larger amount to a drive to avoid the need to increase the drive size later virtio scsi drives can be resized without a power cycle some guest os/file systems do not support drive down sizing check guest os documentation to verify if downsizing a drive is supported security it's important to remember that the remote console provides direct monitor/keyboard mouse access to a virtual machine; gaining console access provides access to the current state of the system (e g if previous user leaves guest os logged in, a subsequent user then has access under that guest os login ) when the spice or vnc console option is enabled for a machine, a console password can be assigned to provide access control a console password, however, does not substitute for using smart login guidelines within the guest operating system (e g individual logins, complex password requirements, etc ) platform permissions allow very granular control of user access utilize user and group permissions to limit access to virtual machines where appropriate networking use virtio network drivers when possible as this will normally provide the best performance most versions of linux operating systems natively contain virtio drivers for windows machines, the latest virtio drivers can be downloaded https //fedorapeople org/groups/virt/virtio win/direct downloads/stable virtio/virtio win iso use legacy network drivers only when absolutely necessary consider upgrading your operating system to a newer version if it will not support virtio network drivers nic teaming is generally not beneficial on vms as network redundancy and load balancing are already provided through the infrastructure using nic teaming within the guest os would consume unnecessary resources and potentially cause issues graphics disable all screensavers within the guest os remove all graphical effects (e g drag or minimize effects) within the guest os data protection a smart data protection plan will include use of both snapshots and syncs system snapshots provide rollback points for an entire system, allowing restoration of the entire cluster to a particular point in time typically it's best to configure your snapshots at the cluster level; this will include everything within that cluster and allows for restoration of the entire system, including individual vms and tenants there is generally no need to configure additional snapshots at the vm level unless there are particular vms that should be captured on a more frequent basis or retained longer (e g database servers) manual vm snapshots can be taken immediately prior to making changes, such as a guest os/application update or advanced configuration change; snapshots can then be saved until vm changes are verified guest software uninstall any guest applications that are intended for other virtualization platforms check the list of automatically started services and disable any that are unnecessary only install software that is actually needed remote console only select the spice console option when using the spice thick client to get audio passthrough/remote usb/video streaming otherwise, it is better to utilize vnc spice should normally only be considered for virtual desktop vms servers should always be configured to use vnc unless there is an absolute need for remote usb; otherwise, there is too much unnecessary overhead with spice changing the remote console option (vnc/spice/none) requires a power cycle and video change machine type q35 is the default emulation for vms and will generally provide the best performance and features typically, when creating a new vm, it's best to leave the default selection for machine type (which will pin the chipset to the latest q35 version currently installed on the physical hosts) older versions of q35 emulation and i440fx emulation options are provided for legacy compatibility there is also an option to select q35 latest as an option for machine type this will automatically upgrade the vm to the newest q35 version available (when vm is power cycled), as new q35 versions become available when a host cluster is upgraded