'''''VM GUEST''''' specifics (Virtual Machine VM)
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = '''Tip:''' Since live mode makes each write go to RAM, increasing the memory assigned to the VM will improve performance; for example, if large files are regularly downloaded.
VM Live Mode is NOT an anti-forensics feature! This is due to the limitations of the virtual machine. For anti-forensics check out Live Mode as '''''HOST''''', described above.
Helpful tips against attack vectors
To keep your live mode unaffected even by malware memorize these instructions and follow them regularly.
'''Table:''' ''VM Live Mode Warnings''
! scope="col"| '''Domain'''
! scope="col"| '''Recommendations'''
| By itself, starting a VM in live mode is not amnesic. Many users are unaware that activities performed inside the VM [[Warning#live|might be stored on the host mass storage device (hard drive, HDD, SSD)]] in locations that are hard to review (for the majority). Extra steps must be performed on the host operating system to minimize these traces -- see [[Anti-Forensics Precautions]], or better, use Live Mode as '''''HOST'''''.
| To prevent malware from remounting the hard drive as read-write it is strongly recommended to use [[read-only|read-only hard drive mode]]. This raises the bar as malware would need to break out of the VM to gain persistence, because there might be data leaks if
* [[read-only|read-only hard drive mode]] is <u>not</u> configured and malware remounted the disk as read-write or broke out of the VM; or
* [[read-only|read-only hard drive mode]] is configured and malware broke out of the VM. <ref>There are two live mode options available, [https://github.com/{{project_name_short}}/grub-live <code>grub-live</code>] and [https://github.com/{{project_name_short}}/ro-mode-init <code>ro-mode-init</code>].
* <code>grub-live</code>: a new boot menu entry is created which must be selected manually, but it is a better failsafe and hence the recommended option.
* <code>ro-mode-init</code>: the boot menu stays the same and the system automatically boots into live mode when it detects a read-only disk, otherwise it boots normally into persistent mode. The advantage of using this approach is that malware running in a VM cannot silently change settings to leave persistent traces.
** [[VM_Live_Mode/ro-mode-init|ro-mode-init documentation]]
** https://forums.whonix.org/t/whonix-live-mode-amnesia-amnesic-non-persistent-anti-forensics/3894/145
! scope="row"| Other Precautions
* <u>{{project_name_short}}</u>: It is recommended to regularly boot into persistent mode for installation of [[Update|updates]]. <br />
* <u>{{project_name_short}}</u>: If live mode is used with {{project_name_short}}, regularly booting into persistent mode is important to keep Tor's normal [[Tor_Entry_Guards|guard]] rotation schedule. <br />
* <u>KVM</u>: Hard shutdowns of a VM can prevent loading of the filesystem with a read-only marked drive on next boot. Do not use 'Force Off/Reset' on KVM to avoid this possibility.
VM Live Mode vs VM Snapshots
Readers of this chapter should already be familiar with {{project_name_short}} live mode, as described in the other chapters on this page, as well as the concept of VM snapshots.
Starting with a clean [[Virtualization_Platform_Security#VM_Snapshots|VM snapshot]] and later reverting to that snapshot should be even safer than using VM live mode. This is because snapshots are enforced from outside the VM, by the virtualizer. Therefore, snapshots are more secure.
It is also worth noting that running VM live mode uses more RAM than is allocated to the guest, since the OS runs entirely in memory. This means that, in some cases, it is more likely for VM live mode to experience [https://en.wikipedia.org/wiki/Thrashing_(computer_science) disk thrashing], where the VM uses up all the allocated memory and becomes significantly slower. The snapshot approach does not have this issue with RAM.
It is difficult to imagine a case currently where the combination of VM live mode with reverting to a clean snapshot would be even safer. Perhaps in the case of a virtualizer bug with snapshots and/or user error forgetting to revert to a snapshot.
For even greater security, the user could consider Live Mode '''''HOST''''' or even host disk snapshots, such as [[Raw Disk Backup]], although this would unfortunately be more cumbersome and time-intensive.
For known issues, see [[Grub-live#Live_Check_Systray_Issues|Live Check Systray Issues]].
Host Live Mode in Combination with VM Live Mode
If the host operating system is booted in live mode, that includes everything that is running on the host. This means it also includes any VMs running on the host.
Therefore it is unnecessary to run VMs in live mode if the host is already running in live mode. The VMs will report that they are not running in live mode but they don't know any better and have no way to know by design.
The user could perform a [[#Functionality Test of Live mode|Functionality Test of Live mode]] to verify this.