IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For example, attempting to live-migrate a disk again after failure
would not work, because a node with the same name would still be
attached.
Mirroring the disk to a shared storage after VM live-migration failure
and then attempting VM live-migration again, would result in
> migration status error: failed - Error in migration completion: Input/output error
This is because for migration completion, all attached block devices
are flushed, but the NBD export does not exist on the target side
anymore.
Fixes: 1da91175 ("block job: add blockdev mirror")
Reported-by: Hannes Dürr <h.duerr@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250728100702.38685-1-f.ebner@proxmox.com
When in 'cancelling' status, wait until the transition to 'cancelled'
happens. Similarly, when in 'wait-unplug' status, wait for the
transition to the next state.
According to the QMP reference docs:
cancelling:
> in the process of cancelling migration.
wait-unplug:
> wait for device unplug request by guest OS to be completed.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250728143042.103045-4-f.ebner@proxmox.com
The QMP reference docs describe the 'device' status as:
> During device serialisation (also known as switchover phase). Before
> 9.2, this is only used when (1) in precopy, and (2) when
> pre-switchover capability is enabled. After 10.0, this state will
> always be present for every migration procedure as the switchover
> phase.
Since Proxmox VE did not use the pre-switchover capability, it has not
been observed before QEMU 10.0. The state is still only reached during
block device inactivation, but it will be reached.
Reported in the community forum:
https://forum.proxmox.com/threads/168619/post-786535
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250728143042.103045-3-f.ebner@proxmox.com
It's possible to run into the default timeout of 5 seconds with quite
a simple and generic Debian 12, kernel 6.1 test VM. Detaching happened
right after doing a lot of IO on the associated drive.
In testing, detaching the drive itself was immediate, and detaching
the VirtIO SCSI controller always took 6 seconds. Use 15 seconds, so
that it's more than twice the value to be on the safe side for the
future.
For completeness, the VM configuration:
agent: 0
boot: order=scsi0
cores: 2
cpu: host
hotplug: disk,network,usb
ide2: none,media=cdrom
machine: q35
memory: 6144
name: Copy-of-VM-Copy-of-VM-apache
net0: virtio=BC:24:11:49:0F:85,bridge=vnet0,firewall=1
numa: 1
ostype: l26
scsi0: sharedlvm:vm-103-disk-0.qcow2,iothread=1,size=4304M
scsi1: sharedlvm:vm-103-disk-1.qcow2,iothread=1,size=4G
scsi2: sharedlvm:vm-103-disk-2.qcow2,iothread=1,size=4G
scsi3: zfs:vm-103-disk-0,size=4G
scsihw: virtio-scsi-single
smbios1: uuid=f3f9952f-aab9-45ef-933d-ee01df474b26
sockets: 2
startup: order=2
vmgenid: 529f6974-6fc8-4196-9fb2-9639f55d31d6
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The default timeout is not appropriate in all cases, e.g. removing a
VirtIO SCSI controller can take more than 5 seconds.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Stat-ing /dev/null worked, because the check in the blockdev module is
for block and character devices and then decides based on the
'media=cdrom' flag whether to use the host_cdrom or host_device
driver. But the result should actually be mocked to represent a block
device rather than a character device.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Without the 'discard-no-unref', a qcow2 file can grow beyond what
'qemu-img measure' reports, because of fragmentation. This can lead to
IO errors with qcow2 on top of LVM storages, where the containing LV
is allocated with that size. Guard enabling the option with
having 'snapshot-as-volume-chain' in the storage configuration for
now. Enabling it always should be evaluated a bit more and tested on
different storages. It is a runtime-only option just affecting how
referencing clusters is handled during discard in qcow2 and nothing
else, so it is also fine for existing images and migration streams.
While 'snapshot-as-volume-chain' is not the perfect proxy, as that's
not only for LVM, it's an experimental feature that covers the LVM
case and it seems like a nice fit to try out the new option on
file-based storages too.
Suggested-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The 'lvmqcow2_external_snapshot' test case uses qcow2 on top of LVM
which can only be used with that option currently.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Discard will only work when the setting is applied to all nodes in
the throttle->fmt->file chain.
Fixes: 2ea50f8b ("blockdev: add helpers to generate blockdev commandline")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Certain options like read-only need to be set on all nodes in the
throttle->fmt->file chain to apply correctly and consistently.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
avoid calling qemu_blockdev_options on a volid+snapshot that is potentially
already invalid if it has been removed/renamed by the storage layer. instead,
generate the node name of the old node that we want to replace/remove directly,
since nothing besides the name is used in this code path anyway..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Link: https://lore.proxmox.com/20250724121042.473947-1-f.gruenbichler@proxmox.com
[FE: make tidy]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
With the switch to '-blockdev', the 'device' property in the return
value of the 'query-blockstats' QMP command is not initialized. This
can be seen in the QEMU source code (the device property is the name
of the block backend and blk->name is assigned a value only in a code
path reached via drive_new()). This was done to avoid confusion/clashes
with node names, because they live in the same namespace as block
backend names.
The node names cannot be relied on either, because an empty CD-ROM
drive does not have an associated block node. So use the qdev ID as a
fallback.
The stats are reported for the block backend, so it does not matter
that the block node structure changed with the switch to '-blockdev'.
Fixes: aaf48d8e ("command line: switch to blockdev starting with machine version 10.0")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250723111105.72422-2-f.ebner@proxmox.com
With the switch to '-blockdev', it is necessary to explicitly specify
the device ID for SCSI drives, see also [0]. Otherwise, the device
paths in '/dev/disk/by-id' would be missing. For IDE/SATA, the paths
are still present with '-blockdev' without additional changes and
VirtIO block did not have such paths even before. The relevant
'ide-{cd,hd}' and 'virtio-blk-pci' devices do not seem to have an
option that would be equivalent to the 'scsi-{cd,hd}' 'device_id'
option.
While the change should be backwards-compatible even with '-drive',
guard it with machine version 10.0 just to be sure.
[0]: a1dce96236
Fixes: aaf48d8e ("command line: switch to blockdev starting with machine version 10.0")
Co-developed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250723111105.72422-1-f.ebner@proxmox.com
QEMU will try to set the write permission on a device even if it's
just the throttle filter that is not marked as read-only. This causes
VM start to fail when a drive with the Proxmox VE-specific 'ro' flag
is configured and also template backup. Properly set the flag also
for the top throttle node.
Fixes: 2ea50f8b ("blockdev: add helpers to generate blockdev commandline")
Reported-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250718154503.179257-1-f.ebner@proxmox.com
This also fixes an issue that the check_and_prepare_fleecing() helper
would always try 'raw' (which might not even be supported) rather than
the storage's default format.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
The $scfg variable in resolve_dst_disk_format() has been unused since
commit 1f961e51 ("resolve destination disk format helper: use volume
format from storage layer").
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This would have caught the issue that was fixed by c4071b7 ("ovmf: use
proper drive properties for temporary efi vars drive"), tested by
temporarily reverting aforementioned commit, which then makes this
test fail.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Our style guide recommends using a hash-access inside another hash as
key, so fix that by introducing an intermediate variable, as here that
makes things simpler to read.
Also define the array explicitly instead of purely relying on auto
vivification.
No semantic change intended.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The name VM.Monitor is ambiguous and made it hard to guess what the
privilege is for. The privilege was only used here and for guest agent
operations, where dedicated privileges were introduced. Since only the
'info' and 'help' commands were usable without an additional
Sys.Modify privilege, the VM.Monitor privilege seems superfluous and
was dropped in pve-access-control. As the information accessible via
'info' is very low-level and often related to the QEMU process on the
system, requiring Sys.Audit seems natural.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250717133711.84715-6-f.ebner@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While HMP (human monitor protocol) commands beside 'info' and 'help'
already require the 'Sys.Modify' permission on '/', certain commands
are better further restricted to be root-only.
Command list and descriptions taken from the output of 'help' and
shortened the descriptions where appropriate.
Many related commands for root-only commands were also made root-only,
for example 'drive_del', because 'drive_add' is or the NBD commands,
because 'nbd_server_start' is. That is being able to only do certain
parts of command groups that are not that useful by themselves. An
exception here is 'qom-get' which is just too useful to be root-only.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250717133711.84715-5-f.ebner@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Make the 'perms' property in the command schema required.
Replace the misleadingly named 'VM.Monitor' privilege with more
precise guest-agent-specific privileges and, for power managment,
the pre-existing 'VM.PowerMgmt' privilege.
There is a basic VM.GuestAgent.Audit privilege for read-only,
informational commands.
There are dedicated privileges VM.GuestAgent.File{Read,Write} for
the file-{read,write} commands. There is a separate
VM.GuestAgent.FileSystemMgmt privilege for filesystem freeze, thaw
and trim. Querying the filesystem freeze status is also allowed with
VM.GuestAgent.Audit.
The VM.GuestAgent.Unrestricted privilege is allowed to do all
guest agent operations, in particular also execution of arbitrary
commands with guest-exec. Querying the result of the guest-exec
command via guest-exec-status is read-only, but it only makes sense in
combination with guest-exec, so it also requires
VM.GuestAgent.Unrestricted.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250717133711.84715-4-f.ebner@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was recently changed without much care as we did never release a
package that included that option to a public repo.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
When creating a new network device from the UI and leaving the MTU
field empty, it defaults to 1500. This is inconvenient in cases where
the MTU of the bridge is not 1500 and lead to some confusion of users
[1]. Containers already inherit the bridge MTU when the field is left
empty, so align the behavior of VMs to be more in line with the more
convenient behavior of containers.
The common case where this was encountered was with creating network
devices on SDN VXLAN vnets. There the default MTU for bridges is 1450,
since VXLAN adds some overhead and we automatically subtract that
overhead from the default bridge MTU (1500) if no MTU is explicitly
set in the zone configuration. Before that users always had to
explicitly set the MTU to 1450 or 1 for every network device created,
which is error-prone.
[1] https://forum.proxmox.com/threads/bug-vxlan-and-mtu.161412
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250717175012.606372-2-s.hanreich@proxmox.com
the new workflow is:
1)
PVE::Storage::volume_snapshot: rename the current to snap
+ allocate the new current with snap backing
(the qemu process have still the inode opened)
2) replace the current to snap in the blockdev graph with reopen
3) add a new current blockdev
3) use block-snapshot to replace the active image with the new current blockdev
with the qemu
also:
move PVE::Storage::volume_rename outside blockdev_replace,
and rename 'blockdev_rename()' to 'blockdev_replace()'.
as we only replace/reopen the blockdev nodes now.
Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
