while it really should not pose an issue for live migrations lets be
on the safe side and also add this only with 3.1 or later machines
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Kernels 4.18+ (4.17+ for evmcs) support new Hyper-V enlightenments for
Windows KVM guests. QEMU supports these since 3.0 and 3.1 respectively.
tlbflush and ipi improve performance on overcommitted systems, evmcs
improves nested virtualization.
It's not entirely clear to me if Win7 already supports these, but since
it doesn't cause any performance penalties (and it works fine without
crashing, which makes sense either way, because Hyper-V enlightenments
are opt-in by the guest OS), enabling it regardless should be fine.
(As opposed to adding a new if branch for win8+)
Feature explanations to the best of my understanding:
hv_tlbflush allows the guest OS to trigger tlb shootdowns via a
hypercall. This allows CPUs to be identified via their vpindex (which
makes hv_vpindex a prerequisite to hv_tlbflush, but that is already
handled in our code). In overcommited configurations, where multiple
vCPUs reside on one pCPU, this increases performance of guest tlb
flushes, by only flushing each pCPU once. It also allows multiple tlb
flushes with only one vmexit.
hv_ipi allows sending inter-processor interrupts via vpindex, once again
making it a prerequisite. Benefits are pretty much as with tlbflush.
hv_evmcs is a VM control structure in L1 guest memory, allowing an L1 guest
to modify L2 VMCS and entering L2 without having the L0 host perform an
expensive VMCS update on trapping the nested vmenter.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
The "guest-shutdown" guest agent call is blocking for some reason, so if
it fails (e.g. agent not installed on guest) only the default timeout of
10 minutes (see QMPClient.pm, sub cmd) would apply.
With this change, if (and only if) a timeout is specified via CLI/API,
it is used instead. In case it is not specified, behaviour stays the
same (default 10 min timeout).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
This should help with the rare case where stop mode backups
fail to restart due to the $vmid.scope not being completely
gone when we want to restart. This queries systemd via dbus,
and if the scope is still there, awaits a UnitRemoved signal
for the scope from dbus.
For now with a 5 second timeout... (given that the processes
are already gone and it's really just waiting for systemd to
wake up, this should be plenty...)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
to acutally allow to set the values requested by #2190 we need to
alter the limit a bit, as else the requested values cannot be save.
Just double it to 512, which should be really enough for this, else
go complain to your software vendor for needing such _hacks_ in the
first place..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
On some occasions e.g. license checking, the manufacturer string in the
SMBIOS settings edit has to allow characters such as whitespaces.
https://forum.proxmox.com/threads/proxmox-and-windows-rok-license-for-dell.53236/
In principle SMBIOS allows to pass any zero terminated string to the
corresponding fields in the structure type 1 (System Information).
By base64 encoding the values clashing of the config is avoided.
Relies on the corresponding patch to pve-manager to obtain base64 encoded values.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Adds the command 'qm cloudinit dump <vmid> <type>' where type is either
'user', 'network' or 'meta' as specified in the API.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Adds the path '{vmid}/cloudinit/dump' and requires the parameter 'type'
that's either 'user', 'network' or 'meta'. Returns the generated config as
string.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
This adds a function to dump the generated cloudinit config. Only one
can be dumped at a time, either 'user', 'network' or 'meta'.
The logic to get user, network and metadata is copied from the other
path that also creates the ISO image to keep it simple and not
complicate the other code path further.
The hash generation for the metadata config is unified between nocloud
and configdrive2 formats. We need it a 3rd time with the new dump
functions so it makes sense to combine it and the metadata config
generation in a single function. The <format>_gen_metadata functions are
each used twice now.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
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>
