this was previously a display field, where submitValue defaults to
false, so we required to enable it explicitly. As it changed to a
combo box we can drop that.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In the VM create wizard we automatically set e1000 for Windows and virtio for
Linux. We should also do this when adding a network device in the hardware
view.
OSDefaults.generic.networkCard (=e1000) is always available. Hence, leave this
as default value for the field and then try to get the ostype via API and
overwrite the default e1000.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
sometimes, the first device in the pci api call is not in a separate
iommu group (see e.g. [0]), but it is active and should work
instead of testing the first, test all, and only show the message
if no device has a set iommu group
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If a guest's QEMU process is 'running', but QMP says 'shutdown' or
'prelaunch', the VM is ready to be booted anew, so we can show the
button.
The 'shutdown' button is intentionally not touched, as we always want to
give the user the ability to 'stop' a VM (and thus kill any potentially
leftover processes).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
as else the window is not centered if it only grows in size after
ExtJS rendered it completely once.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The new boot order property can express many more scenarios than the old
one. Update the editor so it can handle it.
Features a grid with all supported boot devices which can be reordered
using drag-and-drop, as well as toggled on and off with an inline
checkbox.
Support for configs still using the old format is given, with the first
write automatically updating the VM config to use the new one.
The renderer for the Options panel is updated with support for the new
format.
Note that it is very well possible to disable all boot devices, in which
case an empty 'boot: ' will be stored to the config file. I'm not sure
what that would be useful for, but there's no reason to forbid it
either, just warn the user that it's probably not what they want.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
With the introduction of VM.Config.Cloudinit we can set the user,
password and an SSH key without VM.Config.Network permission.
Keep the fallback for VM.Config.Network so custom roles don't break.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
An administrator can set a custom CPU model for a VM where the general user
does not have permission to use this particular model. Prior to this change
the ProcessorEdit component would be broken by this, since the store of the
CPU type selector did not contain the configured CPU model.
Add it in manually if this situation occurs (with 'Unknown' vendor, since
we cannot retrieve it from the API), but warn the user that changing it
would be an irreversible action.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Clean up the code in ProcessorEdit with a view model and fix a bug while at
it - previously, pressing the 'Reset' button on the form would always set
the value of the total core count field to 1, so mark 'totalcores' with
'isFormField: false' to avoid reset.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
The backend treats an undefined value and 0 differently. If the option
is undefined, it will still be set for Windows in config_to_command.
Replace the checkbox with a combobox covering all options.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
I saw some cases where the pending changes just continued to get
triggered for some VMs, even if they shouldn't anymore - effectively
resulting in 3 - 4 concurrent pending changes call at a time.
It could be this, or not, but it's cleaner this way so go for it
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Warn the user when selecting /dev/random or disabling speed limits.
'hardware_counts' is used since technically more than one RNG could be
attached to a QEMU machine. It is limited to 1 however, since the
usefulness of such a setup is more than questionable, considering the
linux kernel only ever uses one hwrng at a time anyway.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Commit f36240c507 (gui: pci passthrough: consider domain in PCISelector)
used 'values.host' without checking if it's set, resulting in an error
when the dialog was opened for a new device (where values.host is
undefined).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
using the better View, ViewModel, Controller style,
while doing this, make it generic so that we can use it for qemu and lxc
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
using an Proxmox.window.Edit, which does many of the things we did
manually, also rewrite is in such way that we can use it for qemu
and lxc
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this improves following behaviours:
* do not loop over items multiple times
(we iterated one time extra for efidisk)
* do not check every item for cloudinit
(we even checked non-disk types)
* make the counts more generic using an object
* also disable cloudinit button when you have one pending
* also disable serial/net button when at limit or the user has
not the right priviliges
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this also fixes the issue that we only showed 4 hostpci devices in
the gui despite raising the limit in the backend to 16
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when a user does not have the right privileges for cloudinit (e.g.
VM.Config.Network), we do not set an editor, which results in a button
that does nothing when pressed
fix this by enabling the button only when there is an editor set
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Avoids having to do the 'Console' -> 'Summary' -> 'Console' dance
everytime the VM is started and the Console window is currently open.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
doc was just bumped, there's no real content, I don't want to bump it
just for this, so replace with link to QM and a fixme comment
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
By ensuring we delete the property if it's true (the backend default)
and set it is false, i.e., like originally (pre, mine and Aaron's
patch), but with reversed user input.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The recent change transformed this checkbox from a negative "No
Backup" to a positive "Backup" did not accounted for changing the
default fallback for the parseBoolean call.
As this would had suggested that disk are backed-up which aren't
backup, it could lead to pretty devastating results...
fixes commit 8e1df0acc5
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Change the behavior from having to activate the `No backup` checkbox to
exclude a disk from backups to having a `Include in backup` checkbox
that is checked by default.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
but remove the default domain '0000' before sending to the backend,
and add it if no domain is given in the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
ObjectGrid (an ancestor of PendingObjectGrid) does already have
a 'reload' function which does exactly the same, so get rid
of the local one here
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
makes no sense to have the, more or less, exact same 25 line method 5
times..
could be moved to widget TK, but that's for another time.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as we noticed at the container side, we should use diffStore in order
to update the button status without delay.
Effectively alls ObjectGrids, and thus their descendants,
PendingObjectGrids use a DiffStore, where we have two effective
stores, a remote store and a local, in-memory, proxy store.
Co-developed-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to improve UX, disabled child fields shouldn't show validation errors
when the parent widget (radiofield) isn't selected anymore.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
with commit 0ea3b8499b we changed how
we define isUsedDisk, which was true for efidisks before, but not
after
use the existing 'isEfi' varable to include them for the move_btn
(but not the resize_btn)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To make it more clear that PVE does not somehow magically injects a
QHA into the VM, but that this can be set if one has installed the
QGA in the VM themself.
So slightly adapt the label by prepending "Use" and adding a hint for
further details.
Also ensure we call it the real name everywhere, i.e., "QEMU Guest
Agent", this makes it a bit more consistent and easier to find
information for users.
Suggested-by: Aaron Lauterer <t.lamprecht@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With introducing pmx-hint to pmg as well, by adding a 'pmx-hint' css-class
to proxmox-widget-toolkit, it makes sense to use the definition everywhere.
this patch drops the .pve-hint class from pve's css and replaces all occurences
in the GUI-source.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Uses a ComboGrid with search feature and a column for vendor. Can be
sorted by both columns.
Default sort is as given in this file, I tried to align it as
* AMD
* Intel
* Other
alphabetically and in QEMU order (as before, seems to be release date?)
within those "groups".
Doesn't work with value set in widget definition (would need to be
preferredValue), but we always call setValue() anyway (and if we don't,
value will be '', aka the default, which is correct too), so just remove
that from ProcessorEdit.js.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As this is annoying else, especially if the change from default to
ovmf BIOS is already a pending change..
A simple hint is enough, we do not do anything with the EFI disk if
OVMF is not set to be used anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Enable USB3 by default. There are no restrictions anymore that the speed
of the dev must match the USB3 speed. The xhci controller can deal with
USB 2 and 1 devices. USB3 devices can be plugged in a USB2 (ehci)
controller. As discussed in [0]
When using a USB device for SPICE passthrough my tests showed that USB2
devices connecting to the xhci controller work but a USB3 device passed
via Spice cannot connect to an ehci controller (no USB3 enabled).
qemu-server 6.0-9 supports USB3 also for Spice USB passthrough. See
commit 733234b [1].
All this means we can get rid of the separate handling of USB3 and non
USB3 devices and leave the decision to the user if USB3 should be
enabled or not.
[0]: https://pve.proxmox.com/pipermail/pve-devel/2019-September/039131.html
[1]: https://git.proxmox.com/?p=qemu-server.git;a=commitdiff;h=733234be04d585febd74c655d8b82d17ebf9e133
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As getUSBValue() always added the "usb3" property if the selected
device was recognized as USB3. But we can now also pass such a device
as USB2 so lift this restriction - which also fixes a bug for USB3
selected devices with the USB3 checkbox set.
The solution also avoids the me.down query, which is nice too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
split the long ternary operation into a common if/else, to make it
readable.
Also, remove the usb3field.isDisabled check as:
1. we do not disable it anywhere anymore
2. if we would, it makes sense to do this anyhow
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Instead of having two times the check if the USB3 setting needs to be
added to the config string it is now checked at one place only.
If USB3 is checked for a non USB3 device it will be attached to the USB2
root hub of the xhci controller.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This was pretty brittle to begin with, on should not attach logic to
CSS class names or the like, if possible.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since commit 03558174ef we can use the
Font Awesome icons without them being shown in the remove dialog, so
convert more to them - they are vectors and look a bit better.
Also ensure that all icons are rendered as fixed width, with fa-fw
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds the following:
* Menu entry to create a new audio device
only clickable if:
* permissions are there
* no audio device exists
* listing in the hardwarew view
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
QEMU 4.0 supports this. Guest needs to have at least Kernel 5.0 for it
to be used.
SSD emulation is still not supported AFAICT, so no change here.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
setData on an 'empty' store does not work in extjs debug mode
setting store to '{}' here does create a store on component creation
so the store is not 'empty'
Signed-off-by: Dominik Csapak <d.csapak@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 qemu-server to pass parameter verification
and correct parsing.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
This allows to select the tri-state (enforce on, enforce off, default
from QEMU+CPU Model) for each CPU flag independently.
For this a grid with a widgetcolumn is used hosting tree radio
buttons for each state. They're marked '+' for enforce on, '-' for
enforce off and the default has no label, as it isn't easy to add in
such a way that it does not confuses people and does not looks
completely ugly.. But, to help people which have a hard time figuring
out what the states mean, a fake column was added showing the current
selected state's outcome in words.
For show casing the new nice interface add all currently supported
flags from out API-
It could be worth to add some selected CPU model awareness, so that
flags are only enabled if they can make sense with the selected
model. But one should be able to add this relative easily with this
as base.
The hardcoded flag lists is not ideal, we should try to generate this
in the future, but here already qemu-server is lacking and this is
rather independent of the fact and can be done later one just fine
too.
Note that this /is/ an *advanced* feature so not visible for all
directly, while I try to document in short what a flag does it surely
isn't perfect and to short to explain all nuances, they should give
enough pointers to know if it's relevant at all (amd / intel cpu) and
for what one should research
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 92572ead6d)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
value is not always a string (depending on the value that changed),
so we have to convert it to a string to have a 'match' function
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
A user which just has the default role PVEVMUser on a VM is able to
edit the CDROM, either to no media or if storage permissions are
available also to other ISOs, through the API. So reflect this again
for the WebUI. We could add a check for "VM.Config.CDROM", but that's
not really worth, if we keep in mind that the Ext.Caps state is
heuristically only.
fixes commit d35b5b2afb
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
