# VM Locks

*[Chapter Index](_index.md) | [Main Index](../SKILL.md)*

direct-io=<boolean> (default = 0)
Honor the O_DIRECT flag passed down by guest applications.

dirid=<mapping-id>
Mapping identifier of the directory mapping to be shared with the guest. Also used as a mount
tag inside the VM.

expose-acl=<boolean> (default = 0)
Enable support for POSIX ACLs (enabled ACL implies xattr) for this mount.

expose-xattr=<boolean> (default = 0)
Enable support for extended attributes for this mount.

vmgenid: <UUID> (default = 1 (autogenerated))
The VM generation ID (vmgenid) device exposes a 128-bit integer value identifier to the guest OS. This
allows to notify the guest operating system when the virtual machine is executed with a different configuration (e.g. snapshot execution or creation from a template). The guest operating system notices
the change, and is then able to react as appropriate by marking its copies of distributed databases as
dirty, re-initializing its random number generator, etc. Note that auto-creation only works when done
through API/CLI create or update methods, but not when manually editing the config file.

vmstatestorage: <storage ID>
Default storage for VM state volumes/files.

watchdog: [[model=]<i6300esb|ib700>] [,action=<enum>]
Create a virtual hardware watchdog device. Once enabled (by a guest action), the watchdog must be
periodically polled by an agent inside the guest or else the watchdog will reset the guest (or execute
the respective action specified)

action=<debug | none | pause | poweroff | reset | shutdown>
The action to perform if after activation the guest fails to poll the watchdog in time.

model=<i6300esb | ib700> (default = i6300esb)
Watchdog type to emulate.


## 10.15 Locks


Online migrations, snapshots and backups (vzdump) set a lock to prevent incompatible concurrent actions
on the affected VMs. Sometimes you need to remove such a lock manually (for example after a power
failure).


```
# qm unlock <vmid>
```


> **Caution:**
> Only do that if you are sure the action which set the lock is no longer running.


Containers are a lightweight alternative to fully virtualized machines (VMs). They use the kernel of the host
system that they run on, instead of emulating a full operating system (OS). This means that containers can
access resources on the host system directly.
The runtime costs for containers is low, usually negligible. However, there are some drawbacks that need be
considered:

- Only Linux distributions can be run in Proxmox Containers. It is not possible to run other operating systems
like, for example, FreeBSD or Microsoft Windows inside a container.

- For security reasons, access to host resources needs to be restricted. Therefore, containers run in their
own separate namespaces. Additionally some syscalls (user space requests to the Linux kernel) are not
allowed within containers.
Proxmox VE uses Linux Containers (LXC) as its underlying container technology. The “Proxmox Container
Toolkit” (pct) simplifies the usage and management of LXC, by providing an interface that abstracts complex
tasks.
Containers are tightly integrated with Proxmox VE. This means that they are aware of the cluster setup, and
they can use the same network and storage resources as virtual machines. You can also use the Proxmox
VE firewall, or manage containers using the HA framework.
Our primary goal has traditionally been to offer an environment that provides the benefits of using a VM, but
without the additional overhead. This means that Proxmox Containers have been primarily categorized as
“System Containers”.
With the introduction of OCI (Open Container Initiative) image support, Proxmox VE now also integrates
“Application Containers” as a technology preview. When creating a container from an OCI image, the image
is automatically converted to the LXC stack that Proxmox VE uses.
This approach allows users to benefit from a wide ecosystem of pre-packaged applications while retaining
the robust management features of Proxmox VE.
While running lightweight “Application Containers” directly offers significant advantages over a full VM, for
use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox
QEMU VM remains a recommended practice.
