Knowledge Base
Virtual Machines
General
9 min
vm console access the remote console provides direct interaction (mouse/keyboard) with virtual machines console toolbar console toolbar all toolbar options, except the exit button, work as a toggle, switching between on/open or off/closed example clicking the chat button opens the chat window, and clicking the button again closes the chat window a button is orange when on/open; white when off/closed scale remote console scales the console window to fill the screen toggle browser full screen activates/deactivates the browser's full screen option change/eject cd rom toggles the view of the cd rom selection form, where an iso file is selected clipboard opens the clipboard window where text can be placed to insert into the virtual machine the close button will close the clipboard window (can also be closed by clicking the clipboard button again) the clear button clears current contents from the clipboard the paste in console button pastes the clipboard contents into the console at the current cursor position power opens/closes the power buttons window \[reset] restarts the vm operating system; does not power down the virtual hardware \[acpi] power down (graceful) \[kill] power down (ungraceful), use as a last resort when guest os is locked and graceful shutdown is not an option extra keys opens/closes the extra keys window, which allows simulating keyboard operations to the machine, such as \[ctrl alt del] \[ctrl] \[alt] \[tab] \[esc] chat opens/closes the chat window where all users that are consoled into the virtual machine can share messages with each other vm fields name displayable characters only; double quotations not allowed; spaces not allowed as first or last character vm name field is changeable after creation enabled default is selected when a vm is disabled, it cannot be powered on description allows for storing additional information about the vm description can prove very helpful in systems with large numbers of virtual machines and/or high virtual machine turnover os family select the os type that will be installed/run on this virtual machine virtualization flags are used to optimize based on the guest os type ⚠️ performance can be adversely affected if an incorrect os family is selected freebsd linux windows other os description provides further documentation area for the vm; intended for additional information about the guest os (e g rc1, sp2, dev edition, enterprise, etc ) snapshot profile defines the snapshot schedule for the individual vm typically, this field is left blank because vm restores can easily be extracted from system snapshots however, defining a snapshot profile here provides a way to perform additional, more frequent snapshots, and/or longer snapshot retention, and/or quiesced snapshots of the vm the selection list includes all snapshot profiles currently available ha group ha group value is used to define node affinity affinity group (value starts with a "+", e g "+webapp1") the system attempts to run vms with the same + ha group on the same node, allowing you to keep related workloads together for optimized performance anti affinity group the system attempts to run vms with the same ha group value across separate nodes this is typically used to provide high availability of an application or service (value must not start with a "+" ) cluster defines the primary choice cluster (at the time of vm power on) to be used for the vm compute resources options include all clusters to which the user has permissions failover cluster defines secondary choice cluster to be used when the primary cluster is unavailable (at the time of vm power on) options include all clusters to which the user has permissions preferred node select the host node on which the vm will first try to start up options include all nodes within the selected cluster cloud init datasource cloud init integration option none no cloud init functionality config drive v2 (standard cloud init) nocloud standard cloud init, intended for configuration without a network connection owner user allows for assigning a user to the given vm assigning owner user will automatically assign list/read permissions for the vm to the given user and will auto delete the vm if the assigned user account is deleted ram the amount of ram to allocate to the vm the ui will allow assigning a vm a higher amount of memory than is actually available however, if the defined amount of ram is not available when a power on command is issued, an error will be thrown and the vm will not start cores the number of cpu cores to allocate to the vm cores can be over provisioned cpu type typically it's recommended to keep the default setting as this will automatically select the cpu type that is optimized for the underlying physical host hardware (at vm creation) a different cpu type can be selected to accommodate legacy operating systems/applications and for allowing porting systems to failover sites where different physical host hardware is employed boot order defines the order in which disk devices are checked for a bootable operating system disk disk, cd rom (default) disk, cd rom, network cd rom cd rom, disk network network, disk disk order id machine type emulated board architecture q35 ahci (recommended) (recommended) pc ide allow hotplug this allows drives and nics to be added without restarting the vm disable if guest os or emulated hardware does not support it console type vnc provides basic graphical console connectivity; no audio or virtual usb support; adequate for most administrative uses spice audio pass through support; usb pass through support (note audio and usb support require spice client software ) serial console when selected, no graphics card is added and all vm output is directed to the serial port a terminal emulator (xterm js) can be used to connect to the serial port none no console access is provided through the user interface console password enabled if enabled, login is required with the specified username/password for accessing the remote console prompts for username and password fields displayed when the console password enabled field is checked usb tablet when selected, a tablet pointer is emulated rather than a mouse, providing for less overhead and network traffic for a command line only vm, with no mouse, this option is unnecessary for spice vms that will use the client agent, this option is unnecessary video card standard vesa 2 0 (default) (recommended) (recommended) recommended for most modern os installations (except where high performance video hardware is utilized) cirrus logic compatible with many installations it is useful for older os versions qxl required when using spice remote console protocol vmware svga ii compatible this driver may be necessary for imported vmware vms virtio provides vga passthrough this is the best option to leverage better video adapter hardware (e g hardware accelerated) on physical nodes; typically the best choice for vdi solutions, where high performance physical video adapters are used this option is not recommended when physical nodes employ low performance, basic video adapter hardware none (headless) no video card is loaded for the vm rtc base sets the time clock for the vm utc universal time clock local time local time, based on the time zone of the host cluster linux typically expects time in utc format windows typically expects time in local time for windows vms this setting should be set to local time , or, appropriate /#guest os fix made within the guest os to use utc uefi selection needed will typically depend on the guest os to be used on the vm (selected=uefi, unselected=bios) modifying this option on an existing vm requires a power cycle of the vm serial port when enabled, a virtual serial port is created; used only for guest os compatibility (e g ubuntu cloud images require a serial port for installation ) ℹ️ when serial console is selected for the console type , this option is not displayed and a serial port is automatically created and assigned to the console boot delay (in seconds) used to control the timing of booting the vm when the owning node is powered on for example, a delay can be specified on a web server to allow time for its database server to boot and load first, before the web server vm is powered on on power loss determines the action taken when power is restored to the vm this can be after a physical power loss or after the node is powered off/on in the ui last state vm will only be powered on if it was on at the time of power loss leave off vm will not be powered on when power is restored (regardless of its state at time of power loss) power on vm will be powered on when power is restored (regardless of its state at the time of power loss) disable power cycle by default, when a reboot is initiated from the guest os, the system will perform a complete power cycle (which re initiates all the vm hardware ) when this option is selected, a guest os initiated reboot will simply reset the guest operating system without a power cycle/hardware reset windows time shift virtual machines (vms) running windows os may experience "time shift", where the guest os will periodically adjust the time to an incorrect value root cause this time shift issue stems from a fundamental mismatch between windows' expectations and modern hypervisor behavior specifically, the time shift comes from virtual hardware clock (rtc) when the vm boots, windows reads the time from the emulated real time clock, which kvm/qemu sets based on the host's time initial clock synchronization this happens at vm startup when windows reads the virtual bios/cmos clock, not through any agent the issue is that windows expects hardware time to be local time, but modern hypervisors (including kvm/qemu) provide utc time this is caused by the windows os, which expects time from the physical motherboard to be in local time (rtc) instead of coordinated universal time (utc) korgrid provides time in utc, which has become the industry standard as it compensates for daylight saving time (dst) changes the guest os will automatically adjust the time when comparing its clock value against an authoritative time source because it assumes the time provided by the hardware is local instead of utc this comparison causes periodic discrepancies because the guest os is unable to adjust the physical node clock to match what it perceives as the correct time hypervisor fix rtc base is an individual vm setting that allows administrators to set the time provided to the os as either local time or utc the value can be found when editing any vm with this configuration setting, administrators can granularly control every machine, though it is important to understand the expected behavior of each option local time setting rtc base to local time will pass the time from the physical nodes to the virtual guest os this emulates the legacy behavior that windows expects when windows compares the local time clock against an authoritative time service, windows will adjust the time within the guest os based on the time zone defined in the windows configuration this can result in unexpected behavior things to consider with local time are the physical node time zone will be presented the same to any guest os the physical node time and the guest os will require proper configuration to avoid issues when daylight saving time (dst) starts or stops each year rtc clocks will need to be adjusted through software historically, issues have arisen when guidelines for dst have changed utc time setting rtc base to utc will pass the time from physical nodes into guest vms as coordinated universal time this is the industry standard for modern software applications that handle time when using the utc setting, windows vms should be configured to recognize that time is presented as universal for most windows operating systems, the adjustment is made in the windows registry by adding a value to recognize "realtimeisuniversal" guest os fix the registry fix realtimeisuniversal=1 is the most elegant solution because it explicitly tells windows the truth about what time format it's receiving eliminates the constant fighting between hypervisor and windows time service works with domain controllers and ntp synchronization for 64 bit operating systems from the guest os, open a command prompt window run the following command reg add "hkey local machine\system\currentcontrolset\control\timezoneinformation" /v realtimeisuniversal /d 1 /t reg dword /f after adjusting this setting, administrators will need to completely power off the vm and then power on the vm before the change takes effect