reverting a nonexisting option did not work with the latest changes
in pve-guest-common, because we do not delete the pending option
in 'add_to_pending_delete' anymore
this had the effect that we had following in the config:
[pending]
option: pendingvalue
delete: option
which would do the deletion code and the pending add code
(e.g. delete the pending cloud init drive and creating it again)
to avoid that situation, we need to remove the option from the pending hash
in the 'delete loop'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
As mentioned in #2408, live-migrating a VM between storages that use
different scsi backends (scsi-hd, scsi-generic, scsi-block) breaks.
To fix, from QEMU 4.1 machine types onward (to not break current
behaviour any more), only use scsi-hd, as in recent versions, there is
almost no difference between the two anyway.
scsi-block (which potentially also breaks) requires a flag to be
manually set on the disk, so we can assume the user knows what they're
doing.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Suggested-by: Daniel Berteaud <daniel@firewall-services.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Each pending options has a hash value which has the 'force'
information encoded as entry. But, this can be { force => 1 } or
{ force => 0 }, so we actually need to check the value and not just
set force to the hash directly, as else we have force always truthy..
fixes a bug where 'detach' caused disks to be destroyed immediately,
because $force parameter was always true since hash is true.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We cannot activate a path, only volume IDs with activate_volumes
(duh)
fixes commit 5c1d42b7f8
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With the changes to pve-storage in commit 56362cf the startup hangs for
5 minutes on ZFS if the cloudinit disk does not exist. Instead of
calling activate_volume followed by file_size_info we now call
volume_size_info. This should work reliably on all storages that support
cloudinit disks.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
When adding a cloudinit disk it does not contain media=cdrom until it is
actually created. This means the check in check_replication fails to
detect cloudinit and it is recognized as normal disk. Then parse_volname
fails because it does not match the vm-$vmid-XYZ format. To fix this we
now check explicitly if the volname matches cloudinit and if so, return
early.
Additionally 2 small cleanups replacing cloudinit regexes with the
same check for volname matches cloudinit.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
When destroying a VM, we intentionally did not remove all related
configs such as backup or replication jobs.
The intention of this flag is to allow the removal of references to
the VM being removed from such configs on destroy.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we can use the shared conf_table_with_pending guesthelper to produce the
config table with the extra delete and pending columns.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
most of the pending changes related code has been moved into
AbstractConfig, so we have to call them as class methods from QemuConfig instead.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
in config GET call, we can now use the new shared methods from
guest-common, namely load_current_config and load_snapshot_config.
the correct method is called depending on the parameters 'current' or
'snapshot'
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
brings us more in line with what we do in pve-container, also it's
good to not use file_set_contents directly if we have all those nice
wrapper interface methods to do things in a safe and guaranteed way.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Between calling vm_destroy and removing the ID from user.cfg (remove_vm_access)
creating a new VM with this ID was possible. VMs could go missing from pools as
a consequence.
Adding a lock solves this for clones from the same node. Additionally,
unlinking must happen at the very end of the deletion process to avoid that
other nodes use the ID in the meanwhile.
Co-developed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
So, while we could just make this a special case before the
config_to_command call and set the $conf->{vmstate} to the statefile
for the case were it's a valid volumeid, the special case handling
get's much easier when we do this outside of that method.
So it's basically a trade-off, and after looking far to long at all
nice revisions Alwin made for me and Fabians request, and even trying
out different approaches, it was never perfect.
But having slight code duplication over the movement mess I proposed
(as I did not had the full picture then, sorry Alwin) felt like the
slightly nicer trade off, as all worked I just use this one now, it
has very clear semantics, easy to understand and that now three lines
are duplicated is IMO irrelevant.
Co-developed-by: Alwin Antreich <a.antreich@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the volume id list is only used to activate before real start and
deactivate later, so use it for the vmstate file too.
This not only makes config_to_command have less side effects, it also
ensures that the vmstate is deactivated again
Co-developed-by: Alwin Antreich <a.antreich@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and use it also for efidisk creation and importdisk
this way we correctly handle zfs-over-iscsi options for those cases
also write tests for it
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
As reported in bug #2402, a system started with "default_hugepagesz=1G
hugepagesz=1G" does not have a /sys/kernel/mm/hugepages/hugepages-2048kB
directory.
To fix, ignore the missing directory in hugepages_mount (since it might
not be needed anyway), and correctly check if the requested hugepage
size is available in hugepages_size instead.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
In general it matters where a command line options is positioned
inside a QEMU command, so we want to actually also check the order in
the cfg2cmd test, to do so we need to avoid false positives like this
added.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thanks to Gilberto Nunes for finding a bug where the VM would not start
with foldersharing enabled and the qemu agent option disabled [0].
The cause was that the device org.spice-space.webdav.0 would not find a
virtio-serial-bus in this situation.
Since we always create a virtio-serial-bus for the spice vdagent it
seems sensible to use that also for the foldersharing device by moving
it in front of the other spice devices.
[0]: https://pve.proxmox.com/pipermail/pve-devel/2019-October/039441.html
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This removes the cloudinit disk from the list of drives to clone. As the
cloudinit disk is recreated on every VM start, it's not necessary to
clone it.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
The reason for why we did not do this in the first place was the fact
that the "usb3" flag could be set in older qemu-server versions, we
just ignored it but not filtered it out of the config..
That means there can be VMs out there which would now become a
different HW layout, and issue for migration and live-snapshot
restore.
But, actually, while the "usb3" property could be set it allowed to
start the VM in only if an additional USB devices was added to the VM
with USB2, or the VM uses "q35" based machine - as else no "ehci" was
available, and thus the "ignored" USB3 - SPICE could not get attached
anywhere -> QEMU chickened out.
And if a user had a configuration where this could started we have
still a bit luck, live-migration was not possible as the "can't
migrate VM which uses local devices:" check still hit, as in
qemu-server older than 6.0-8 we explicitly checked for "spice" when
seeing what usb device were not local, so a "spice,usb3=X" was always
(luckily) wrongly detected as local device -> migration was blocked.
So we only have one case left: restoring a live-snapshot. Here sadly
there seems no way out, it was possible to do with a "spice,usb3=1"
usb device, and thus all Snapshots taken on such VMs after they had a
clean restart on PVE 6 (to have a machine version >= 4.0) are broken
- but can be easily fixed by removing the "usb3=1" from the
problematic snapshot config.
As restoring a snapshot can be repeated more than once even on
failure without rendering the snapshot or VM permanently unusable,
this should be a reasonable compromise.
I strongly believe that the chance is so small that no one is
affected in practice and the property description mentioned that it
was not supported. If anybody is affected on snapshot restore we can
help them on a case-per-case basis.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The fix introduced in commit bf4a933 did not work as intended. We're
iterating over the $oldconf, not over $virtdev_hash. This means
$drive->{is_cloudinit} is always undefined. Instead use the $exclude_cloudinit
parameter from drive_is_cdrom().
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
and add "current" as keyword, further remove the parenthesis for the
post-if, to adapt to Proxmox general perl code style
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thanks to Stefan and Thomas for the suggestions.
Changes from v1:
* update parameter description
* warn instead of die
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
otherwise a user with only VM.Config.HWType cannot
delete a 'pending' usbX: spice or serial: socket option
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The check relied on the fact that in a regular use case a usb device of
type spice would not have any other settings like `usb3=1`. An exact
match worked fine for this.
This patch changes the behaviour and makes it possible to migrate VMs
with Spice USB devices that have additional usb options set.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
To not change current behaviour and thus breaking live migration USB3
for a Spice USB device requires Qemu v4.1.
The old behavior was that even though technically it was possible to
the set `usb3=1` setting, it was ignored. The bus was hardcoded to
ehci. If another USB2 device was added or the machine type was set to
Q35 an ehci controller was present and the VM was able to boot.
With this patch the behaviour is changing and the bus is set to xhci if
USB3 is set for the Spice USB device and the VM is running under Qemu
v4.1.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
this creates a reboot request file (inspired by pve-container)
and relies on the 'qm cleanup' call by the qmeventd to detect
and restart the vm afterwards
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we want to reuse most of the code in the locked context of vm_stop
for vm_reboot (since it really is just a vm_stop with a
create_reboot_request in there) so we factor that out into
_do_vm_stop
and note that it has to be called in a locked context
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if the reboot trigger file was set, start the vm again
also cleanup the reboot trigger on vm startup, to prevent
leftover files to trigger a reboot at the next shutdown
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
try to increase variable declaration to use locality, reduce
duplication of same variable names used, and try to cleanup a bit in
general..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For non pci express passthrough additional addresses are reserved.
For pcie passthrough pcie root ports are needed (unless guest is like
windows 7).
The first 4 pcie root ports are defined by default in the pve-q35*.cfg
files. If more than 4 pcie devices are passed through the needed root
ports are created on demand. This helps to keep live migration possible
without adding a new pve-q35*.cfg file.
For the windows 7 like guests additional addresses are reserved as well.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This adds a new config option called `spice_enhancements` with two
optional settings:
* videostreaming
* foldersharing
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Live migration with a local cloudinit disk was never intended to work. It did
however work to an extent that the migration completed but the disk on the
source node could not be deleted. Now die if a live migration is started with
a local cloudinit disk.
With the GUI changes live migration is already disabled as it recognizes the
cloudinit disk as a local resource.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
for some reason not setting port results in a port of '65535' which
triggers an execption in http-server anyevent, so we set the port to 0
also, we have to read the ticket from stdin even for 'unix' type secure
migration
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we now also save the mtime of the binary and cache per binary (for each
arch; this is done so we have it already when we sometime decide
that we want to split the qemu package for each arch)
so that we get the real version if only pve-qemu-kvm was updated
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
A generated VM with default values does not set the memory key in the
configuration. Hence the size of the state file for a suspend had only
the default size of the state itself and not in addition twice the
configured memory.
The patch uses the static defaults from the JSON schema if the memory
key is not set.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
The latest changes to our audio device implemenation [0] changed the
naming of the device id to "audio<id>" which in practice resulted in
"audio0".
This conflicts with the predefined audio device in the Q35 configs
that is also using "audio0". The result is that a VM with a
configured audio device and Q35 type will not start.
While we just would had removed the audio0 device if we had detected
this earlier in the new 4.0 q35 config, we cannot do so anymore due
to migration compatibility.
So rename the device from "audio$id" to audiodev$id".
Co-authored-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Both flags were causing issues and have been made into optional flags to
be manually selected by the user if needed.
The supported flags have been merged into a single list for convenience.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
QEMU 4 adds the `-audiodev` parameter to explicitly specify the audio
backend. Setting it avoids occasional error messages when starting a
virtual machine with an audio device and qemu wants to connect it to the
physical audio device.
For now only SPICE is supported as it's also the biggest use case.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
die if we get some unknown value, which is either a bug (new dev type
added to enum but not here) or a user manual edit error, good to
ccatch both
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Until now audio devices had to be added manually with the `args` option
in the VMs config file. This adds a new config option to define an audio
device. It is called `audio0` with the extra `0` to be prepared should
we ever implement support for more than one audio device.
Supported devices are:
* ich9-intel-hda: Intel HD Audio Controller, emulates ICH9
* intel-hda: Intel HD Audio Controller, emulates ICH6
* AC97: useful for older OSs like Win XP
If any of the `intel-hda`s is selected two additional devices will be
created: hda-micro and hda-duplex. The `*intel-hda` controllers need at
least one of them as they emulate microphones and speakers (hda-micro)
or line in and out devices (hda-duplex).
Having both is deemed best practice to avoid problems if some software
needs one of the other kind of output/input ports.
I also cleaned up some old, commented out, code regarding audio devices.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
with qemu 4.0 we can make use of the new pcie-root-ports with settings
for the width/speed which can resolve issues with some hardware combinations
when negioating link speed
so we add a new q35 cfg that we include with machine types >= 4.0
to preserve live migration of machines without passthrough but q35
for details about the link speeds see:
pcie: Enhanced link speed and width support
https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02827.html
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If 'now' is passed to the startdate option, the kvm start fails with
below failure.
kvm: invalid datetime format
valid formats: '2006-06-17T16:01:21' or '2006-06-17'
With this patch, 'now' is ignored and not passed to the rtcflags (-rtc).
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
e.g. local storage was considered not allowed for offline migration
even if it is available on all nodes, this should now be fixed as it
is now considered available on all nodes if a local storage isn't
restricted to a specific subset of the available nodes. The user is
responseable to make sure that the datacenter storage config reflects
the actual setup, so there is no additional check for local storages
which aren't available on all nodes if they are not explicitly marked
at datacenter level.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
This is required for Windows to recognize the ISO and as a result the cloudinit
config. This is the minimum to get any config working at all for windows.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Regression from change allowing timeouts to be set, now shutting down
also works without timeouts again (previously qmp failed because of
the unknown "timeout" parameter passed to it).
We always delete the timeout value from the arguments, regardless of
truthiness. "delete" returns the deleted element, deleting a
non-existant hash entry returns undef, which is fine after this point:
"deleting non-existent elements returns the undefined value in their
corresponding positions."
- https://perldoc.perl.org/functions/delete.html
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
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>
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>
The 'migrate_speed' can be set in the VM config. Additionally the 'migrate'
bwlimit from datacenter.cfg (storage-specific limits play no role for
memory+state migration) or the parameter provided to the API call can restrict
the speed. Take the lower of the two.
This patch also refactors the setting of migrate_speed and comments for clarity.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
disk is not copied to the target node but still deleted on cleanup
(phase3_cleanup).
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
create a fixed size cloudinit disk if it is referenced in config and
does not exist. the size of the disk created when first added to the
config is reduced to 4MiB to match the one created in
commit_cloudinit_disk.
maximum file size per snippet file (network, user, meta) is increased to 1MiB.
preparation for offline migration without the cloudinit disk (that is
always regenerated on start).
also fixes#1807, although a further patch is required to change the
vmid on restore
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
configdrive2 uses /etc/network/interfaces style config instead of the
official yaml one. this does not allow quoting of the ip addresses.
Tested with Windows Server 2016.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
this makes it possible to give a storage for state saving, if one
wants to use a different storage than for snapshots or does not
want to save this info into the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if a vm has the 'suspended' lock, we resume with the saved state
and remove the lock, the saved vmstate and the saved runningmachine
after the vm started
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the idea is to have the same logic as with snapshots, but without
the snapshotting of the disks, and after saving the vm state (incl memory),
we hard shut off the guest.
this way the disks will not be touched anymore by the guest
to prevent any alteration of the vm (incl migration, hw changes, etc) we
add a config lock 'suspend'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we map scsiX to virtioscsiX/scsihwX when we use virtio-scsi-single to add
and iothread so we have to map it back when we delete an iothread, else the
parsing fails with
'invalid drive key: virtioscsi0'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
qemu-img uses the qemu default initiator name 'iqn.2008-11.org.linux-kvm'
since we use the one of the host (/etc/iscsi/initiatorname.iscsi) when
using it with a running vm, we want to using it also when moving a disk
with qemu-img
to do that we have give qemu-img the image in as a full option string
this fixes the issue that we could not move an zfs-over-iscsi disk
without allowing the default qemu initiator
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Adds the 'cicustom' option to specify either or both network and user
options as property strings. Their parameters are files in a snippets
storage (e.g. local:snippets/network.yaml). If one or both are specified
they are used instead of their respective generated configuration.
This allows the use of completely custom configurations and is also a
possible solution for bug #2068 by specifying a custom user file that
contains package_upgrade: false.
Tested with Ubuntu 18.10 and cloud-init 18.4.7
Signed-off-by: David Limbeck <d.limbeck@proxmox.com>
we also need to set the link status if the whole device changed,
otherwise a change of macaddress allows a network connection even
if link_down is set to 1
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
with such a shared memory device, a vm can share data with other
vms or with the host via memory
one of the use cases is looking-glass[1] with pci-passthrough, which copies
the guest fb to the host and you get a high-speed, low-latency
display client for the vm
on vm stop we delete the file again
1: https://looking-glass.hostfission.com/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This allows to set the wwn parameter for ide, sata and scsi disks in the VM
config and passes it to the qemu command on execution.
VirtIO Block does not supports this property, so exclude it from
there.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Space or newline after ':' is recognized as a mapping and as a result an
ipv6 ending in ':' is not parsed as a string. The solution is to quote
the address. For consistency all other addresses (including mac) are
quoted.
Signed-off-by: David Limbeck <d.limbeck@proxmox.com>
when no numaX config options were present we returned the
hash as a list instead of a hash reference...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Currently Proxmox VE always deallocates HugePagesTLB
when starting a new machine and it makes it impossible
to preconfigure kernel /proc/cmdline with persistent allocation.
This change makes deallocation to prefer defaults set by /proc/cmdline,
by parsing the cmdline and respecting hugepages= and hugepagesz=.
Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu>
commit 3c23aa808c tried to fix a issue
where after a stop mode backup a scope could still linger around, but
it actually removed the wrong check. If we want to remove a
lingering, not yet cleaned up, scope we need to check if said scope
exists not if a VM process is still running. While they are corelated
the scope will always get cleaned up _after_ it's processes are gone.
Should fix#2043, but as this is seemingly not that easy to fix one
for all I'll put the should as disclaimer here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Wolfgang Bumiller <w.bumiller@proxmox.com>
this adds a new config option for it, and executes it on four
points in time:
'pre-start'
'post-start'
'pre-stop'
'post-stop'
on pre-start we abort if the script fails
and pre-stop will not be called if the vm crashes or if
the vm gets powered off from inside the guest
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The qm CLI command offer the config and showcmd functions. Both of those
outputs may vary with respect to a given snapshot. This adds a switch
that shows the corresponding snapshot's config and command line.
The code needs a newer libpve-guest-common-perl, thus bumping the
dependency.
Signed-off-by: Rhonda D'Vine <rhonda@proxmox.com>
this patch allows the user to explicitely set a virtual vga,
even when using the 'x-vga' flag, this is sometimes necessary,
as some users need the 'x-vga' flag on the pci device,
but still want to use a virtual vga
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
with this, a user can set the hv_vendor_id independently of
any 'x-vga=on' setting he may or may not have configured.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
commit 4530494bf9 introduced an
regression with local disk migrations if the VM is online and thus
needs to live migrated and no target storage was passed as parameter.
We made the hack to write "1" to the targetstorage option in this
case obsolete, but it was still used on deciding if there are any
drives to mirror at all. Here it is enough to check if there are any
'online_local_volumes' because that hash gets only filled if we can
and are told to live mirror local disk on migrations anyway. Also,
we abort early if local disks are found and the 'with-local-disks'
option is not set.
This was reported at:
https://forum.proxmox.com/threads/livemigration-with-localdisk-doesnt-coppy-and-data-from-the-hdds-anymore.50744/
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the check for targetstorage in:
if ($self->{running} && $self->{opts}->{targetstorage} && $local_volumes->{$volid}->{ref} eq 'config') {
was obsolete, as we always set the tragetstorage opts variable to '1'
in a broader "use same sid for remote local" check above.
So removing it leads to the same if truthtable but fixes the
check if we should fallback to the volume's SID if targetstorage is
not set, as else it seemed to be always set, and '1' is naturally not
a correct stroage ID.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
targetsid was not used, for disk unused (offline copy)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Win7 is very picky about pcie assignments and fails with
'error 12' the way we add hospci devices.
To combat that, we simply give the hostpci device a normal port
instead.
Start with address 0x10, so that we have space before those devices,
and between them and the ones configured in pve-q35.cfg should we
need it in the future.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When not setting 'vga' we would get a warning:
Use of uninitialized value $type in string eq at
/usr/share/perl5/PVE/QemuServer.pm line 2026.
This patch changes the order of the conditions and checks if $type is set
before using it, so that we do not get the warning anymore.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
so that one can explicitly disable the vga without having to specify
a serial port as display, this is mostly useful for very special
and custom gpu passthrough setups which have to be specified with
'args' and for setups which do not care about any display (not even serial)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
there is nothing that should be really affected by this, but
even then, this option is only for experts and people using this
should know what they are doing
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if we migrate a vm we call cleanup but the logging looks like:
Starting cleanup for 101
trying to acquire lock...
OK
Configuration file 'nodes/pve-ceph-01/qemu-server/101.conf' does not exist
with this patch, we omit any logging in the case we do not have the config,
since we cannot know what to clean up
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When live migrating, with a q35 machine will get the qemu version
encoded in the machine type, for example,'pc-q35-2.12', so we need to
allow this too and cannot expect that all q35 machine have
q35' in verbatim as their type.
So, when migrating such a machine live, we missed to include the q35
cfg because we didn't allowed versioned q35 machine types, which then
failed the migration.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since lspci does not split between id and function anymore,
there is no need to plug id + function together
also we can remove the capture groups from PCIRE
since parse_property_string does this check for us
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
with this, we are able to create and use mediated devices,
which include Intel GVT-g (aka KVMGT) and Nvidia vGPUs, and probably more
types of devices in the future
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we reverse the direction of the event socket (this does not
prevent live migration) and point it to wher qmeventd listens
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this is intended to be used with qmeventd, to do
the necessary cleanups when qemu crashes or is being
shut down from within the guest
this can also be the point where we could introduce
shutdown/stop/reboot hooks
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
On arm we start off with a pcie bridge pcie.0. We need a
keyboard in addition to the tablet device, and we need to
connect both to an 'ehci' controller.
To do all this, we also pass the $arch variable through a
whole lot of function calls to ultimately also adapt the
hotplug code to take care of the new keyboard device.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This was never actually used, but we want to use it as
alternative to checking /proc/cpuinfo for 'hvm' on ARM.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
SLAAC previously set 'auto' which is not supported by nocloud network
config. On an up-to-date Ubuntu this should work as it uses 'dhcp' for
both dhcp and SLAAC. For others it was invalid anyway.
Signed-off-by: David Limbeck <d.limbeck@proxmox.com>
with commit 55655ebc32
we changed $vga to a parsed hash instead of a string
and forgot to check the property type in one place
this fixes an issue where a vm with a gpu passed through
with x-vga=on could not start
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we change 'vga' to a property string and add a 'memory' property
with this, the user can better control the memory given to the virtual
gpu, this is especially useful for spice/qxl since high resolutions need
more memory
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When enabled, the `ssd` property exposes drives as SSDs (rather than
rotational hard disks) by setting QEMU's `rotation_rate` property [1,
2] on `ide-hd`, `scsi-block`, and `scsi-hd` devices. This is required
to enable support for TRIM and SSD-specific optimizations in certain
guest operating systems that are limited to emulated controller types
(IDE, AHCI, and non-VirtIO SCSI).
This change also unifies the diverging IDE and SATA code paths in
QemuServer::print_drivedevice_full(), which suffered from:
* Code duplication: The only differences between IDE and SATA were in
bus-unit specification and maximum device counts.
* Inconsistent implementation: The IDE code used the new `ide-hd`
and `ide-cd` device types, whereas SATA still relied on the deprecated
`ide-drive` [3, 4] (which doesn't support `rotation_rate`).
* Different feature sets: The IDE code exposed a `model` property that
the SATA code didn't, even though QEMU supports it for both.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1498042
[2] https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00698.html
[3] https://www.redhat.com/archives/libvir-list/2012-March/msg00684.html
[4] https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg02024.html
Signed-off-by: Nick Chevsky <nchevsky@gmail.com>
we will use this for the qmeventd, but we have to limit this
to qemu 2.12, because we cannot add this during a live migration
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Instead of our own. The code is almost the same, but the
upstream implementation uses qemu's transactional system and
performs a drain() on the block device first. This seems to
help avoid some issues we run into with qcow2 files when
creating snapshots.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
do not use $1 do write out config, if code gets added this may easily
get overwritten, as vmgenid is a fixed key just hardcode it.
also move the comment to where it actually belongs
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This caused a few hiccups with qemu 3.0...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Acked-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of overwriting the 'machine' config in the snapshot,
use its own 'runningmachine' config only for the snapshot
this way, we do not lose the machine type if it was
explicitely set during the snapshot, but deleted afterwards
we also have to adapt the tests for this
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
$newconf->{pending} is a reference to an empty hash, which is not falsy,
thus we always printed the warning
so check if there are actual values there and if yes,
give the names of the properties for which pending changes are found
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> The following are important CPU features that should be used on
> Intel x86 hosts, when available in the host CPU. Some of them
> require explicit configuration to enable, as they are not included
> by default in some, or all, of the named CPU models listed above.
> In general all of these features are included if using “Host
> passthrough” or “Host model”.
>
> pcid: Recommended to mitigate the cost of the Meltdown
> (CVE-2017-5754) fix. Included by default in Haswell, Broadwell &
> Skylake Intel CPU models. Should be explicitly turned on for
> Westmere, SandyBridge, and IvyBridge Intel CPU models. Note that
> some desktop/mobile Westmere CPUs cannot support this feature.
>
> spec-ctrl: Required to enable the Spectre (CVE-2017-5753 and
> CVE-2017-5715) fix, in cases where retpolines are not sufficient.
> Included by default in Intel CPU models with -IBRS suffix. Must be
> explicitly turned on for Intel CPU models without -IBRS suffix.
> Requires the host CPU microcode to support this feature before it
> can be used for guest CPUs.
>
> ssbd: Required to enable the CVE-2018-3639 fix. Not included by
> default in any Intel CPU model. Must be explicitly turned on for
> all Intel CPU models. Requires the host CPU microcode to support
> this feature before it can be used for guest CPUs.
>
> pdpe1gbr: Recommended to allow guest OS to use 1GB size pages.Not
> included by default in any Intel CPU model. Should be explicitly
> turned on for all Intel CPU models. Note that not all CPU hardware
> will support this feature.
-- https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/
Some storage like rbd or lvm can't keep thin-provising after a qemu-mirror.
Call qga guest-fstrim if qga is available and fstrim_cloned_disks is enabled
after move_disk and migrate.
Co-Authored-By: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
changelog v2:
- remove hash
- remove check if cdrom
if we try to delete a snapshot, and that is disk from the snapshot
is not attached anymore (unused), we can't delete the snapshot
with qemu snapshot delete command (for storage which use it (qcow2,rbd,...))
example:
...
unused0: rbd:vm-107-disk-3
[snap1]
...
scsi2: rbd:vm-107-disk-3,size=1G
-> die
qmp command 'delete-drive-snapshot' failed - Device 'drive-scsi2' not found
If drive is not attached, we need to use the storage snapshot delete command
writes the given content to the file
the size is at the moment limited by the max post size of the
pveproxy/daemon, so we set the maxLength to 60k
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this api call reads a file via the guest agent,
(in 1MB chunks) but is limited to 16MiB (for now)
if the file is bigger, the output gets truncated and a
'truncated' flag is set in the return object
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
on the commandline the implementation for exec is a bit different
because there we want (by default) to wait for the result,
as opposed to the api, where it is enough to return the pid and
let the client handle the polling
this behaviour is optional and can be turned off, as well as the
timeout of 30 seconds
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this imitates the qemu-guest-agent interface
with an 'exec' api call which returns a pid
and an 'exec-status' api call which takes a pid
the command for the exec call is given as an 'alist'
which means that when using we have to give the 'command'
parameter multiple times e.g.
pvesh create <...>/exec --command ls --command '-lha' --command '/home/user'
so that we avoid having to deal with shell escaping etc.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this executes the guest agent command 'set-user-password'
with which one can change the password of an existing user in the vm
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
tells an user what would get touched, so he has a chance to fix
unwanted things before changes are actually made.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Else an user has no idea what, or if something happened.
Gets printed to tty when using qm rescan or to tasklog for the case
where we do a rescan after restoring a backup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Unused disk(s) appeared after a rescan of storages. Especially shown
with ceph pools, where two storage entries are made, <storage>_ct and
<storage>_vm. The rescan method did include images from both storages.
This patch filters any storage not containing the content type 'images'.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
when a vm is suspended (e.g. autosuspend on windows)
we detect that it is not running, display the resume button,
but 'cont' does not wakeup the system from suspend
with this we can wake up suspended vms
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Move the locking inside worker, so that the process doing the actual
work (create or restore) holds the lock, and can call functions which
do locking without deadlocking.
This mirrors the behaviour we use for containers, and allows to add
an 'autostart' parameter which starts the VM after successful
creation. vm_start needs the lock and as not the worker but it's
parents held it, it couldn't know that it was actually save to
continue...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the not definedness check is unecessary here, since it does not
do anything then, and to check balloon twice is also not necessary
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Deleting the balloon config entry means resetting it to its
default. This means having a balloon device but not actually
doing any ballooning with it (iow. resetting the VM's
'balloon' value to its specified memory.).
Hotplugging a balloon device (coming from explicit '0' to
any other value (including deleting it)) is not possible.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To avoid potential cleanup & post-start actions to cause
unwanted processes (such as gpg-agent) to be started as part
of the scope, as the enter_systemd_scope() function causes
the current process to enter the scope.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
cloning a vm means copying the current state, not the
state of 'some time in the future, when the vm is started again'
we should not copy the pending changes, which also fixes the
issue that we got a wrong pending change on the disks,net,smbios,etc.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when using q35 as machine type, there are nested pci-bridges,
but we only checked the first layer
this resulted in not being able to hotplug scsi devices,
because scsihw0 was deeper in the pci-bridge construct, we did not see
it and tried to add it (which fails of course)
this patch checks all bridges, regardless how deeply nested they are
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
