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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This commit addresses the following things:
* There can be multiple independent snapshot tree roots, display them
all
* If a snapshot defines a parent that doesn't exist, it is now
considered a snapshot root
There is a potential issue (which was also before and also affects the
GUI): circular snapshot trees. That plays into the second mentioned
issue above. If you manage to have a snapshot that defines a
non-existing root in the config, and then create a snapshot with that
exact name as a child of that snapshot, it would create a circular
dependency. This would have to get addressed in the GUI too.
Signed-off-by: Rhonda D'Vine <rhonda@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for both vm_mon_cmd calls. under certain circumstances, the following
sequence of events can otherwise fail when live-migrating under load:
S...source node
T...target node
0: migration is complete, handover from S to T starts
1: S: logically move VM config file from S to T via rename()
2: S: rename returns, config file is (visibly) moved on S
3: S: trigger resume on T via mtunnel
4a: T: call vm_resume while config file move is not yet visible on T
4b: T: call vm_resume while config file move is already visible on T
4a instead of 4b means vm_mon_cmd will die in check_running unless
vm_mon_cmd_nocheck is used.
under heavy pmxcfs load and a slow cluster/corosync network, there can
be a few seconds of delay between 1 and 2, with a subsequent race ending in 4a
instead of 4b.
this issue was reported to occur on bulk migrations.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
cloudinit is just completely broken...
Until we rewrite this to a sane designe (i.e., never backup, mirror,
... any CI disk anywhere - the state is in the config and gets
created on start and deleted on stop anyway) do this..
Co-developed-by: Mira Limbek <m.limbek@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Resolves the issue of restoring a VM that has a cloudinit drive
configured to a new VMID. The VMID of the disk name gets now remapped
correctly and in the process the cloudinit disk is created with the same size
as in PVE/API2/Qemu.pm create_disks and in PVE/QemuServer/Cloudinit
commit_cloudinit_disk as the same constant is used.
This is done by matching any line starting with either 'ide', 'sata' or
'scsi' and then check if it is a cloudinit drive. As cloudinit drives
are attached as cdrom, only those 3 are possible. For the cloudinit
check we use 'parse_drive' followed by 'drive_is_cloudinit' so no custom
regex is necessary.
'--targetstorage' is also taken into account on restore now for
cloudinit disks. If a target storage is specified the format is either
kept if possible, or changed to the default of that storage.
This should fix#1807 completely. The restore error was already resolved
with commit 7e8ab2a, but the vmid of the disk might not have matched the new
one.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
The variable is used instead of the literal value so we have one single
place to change the actual value of every use.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
with commit 64d1a6a it's now possible to specify a format other than raw
or qcow2 when creating VMs. This can lead to an error when cloning the
VMs and a cloudinit disk with a different format is attached (e.g.
vmdk).
We use QEMU_FORMAT_RE in drive_is_cloudinit and according to the
QEMU_FORMAT_RE we support 7 different formats.
With this change we add any format other than 'raw' as '.<format>' to the
name and no longer die on any other format. Cloudinit disks with invalid
format are not cloned as the drive is recognized as cdrom, not cloudinit.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
file_size_info can't find the file if it is not available, e.g.,
RBD storage with KRBD or LVM where the volume was not yet activated,
returns then 0, which we interpret as the disk not existing, thus
call vdisk_alloc which errors as the disk, in fact, really already exists.
With this patch we call activate_volume before trying
file_size_info, so if the volume exists we get it available and else
we can really create it.
If the disk does not exist and is created with vdisk_alloc we still
require an additional call to activate_volume for the new disk.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
remove now out of date commen about 'our', left over from previous
revision
Pass firs $prefix directly to function and some other small stuff
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The look of the tree is based on the GUI variant, so that we have a
consistent output when run multiple times, too.
Signed-off-by: Rhonda D'Vine <rhonda@proxmox.com>
we know the size, and even if a storage plugin pads this up (it
mustn't alloc something smaller, but something bigger can be OK) we
know that our 4MB is OK, and can only be used anyway to make this
compatible between storage plugins.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
use file_size_info to check for existence of cloudinit disk instead of
'-e'. It uses `qemu-img info` to get some file info, which can handle
rbd, and various other paths for volumes not exposed as normal file
or not mapped, yet.
this addresses a problem with rbd where the path returned available
is not checkable with '-e'.
Any size > 0 is interpreted as the image existing.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The restore of a backup from a VM template will first restore the VM and then
convert the restored VM back into a template.
This automatically performes the steps of the current behaviour, where the user
has to manually convert the restored VM back to a template.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
When a Cloudinit image is created, we allow choosing
the format as parameter.
So, the parameter should also be taken into account.
The default for Cloudinit will stay qcow2 on directory storages.
using the same logic like serialX: socket
users need VM.Config.HWType for usbX: spice
but only root can add/remove real devices
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since we do not want the user to change a device which has a real
devices already set, we have to check it later when we have the config
so we do not have to give the params to vm_check_modify_config_perm anymore
also improve the regex to \d+
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the clone API calls (target) 'storage' parameter is optional as we
simply use the source storage in this case, but we did not handle
this case when we added the bandwidth_limit abillity, address that.
This patch only pushes the storage parameter into the storage_list array
if it is defined.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
for migrate_vm, clone_vm and move_vm_disk and extract it. The 'migrate_vm' call
passes it to PVE::QemuMigrate->migrate for handling.
Additionally the bwlimit option's description of the 'create_vm' call gets
consistent capitalization of I/O.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
used for online local disks via qemu_drive_mirror
Add TODO comment for offline disks, as clone_disk calls `qemu-img
convert`, which does not have a bandwidth limit parameter.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
