'import storage' is a bit amibuous as to whether it's the storage to
import from or to. To fix that, change it to 'source storage'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
For ova import, the help text for live-import is not really fitting, as
there is no 'old' vm that needs to be stopped, etc.
So show a more appropriate one if we import an ova
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
but only when we detect the 'ova-needs-extraction' warning.
This can be used to select the storage where the disks contained in an
OVA will be extracted to temporarily.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
It's hard to cram a easy to understandable meaning in the space we
have, to get a bit more space move the warning hint to a separate line
and use the box-label to show an always visible hint about the VM to
be stopped previously.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
handle mapping purely in the change handler for the prepare-for-virtio
checkbox and avoid any such mapping logic in the renderer, while
slightly longer the code is much easier to reason about.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Otherwise changes will persist, e.g., disabling a CDROM drive won't
work if the values got assembled for the "Resulting Config" tab
before. Same for the "Prepare for VirtIO" checkbox, there one got the
disk twice, once as (old) mapped SATA and once as (original) SCSI.
To fix this do not work on a reference of the original VM config, but
rather always copy that to a new object before applying the form
values.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Aaron originally designed the new "unique MAC address" checkbox after
this one for alignment reasons [0]. I changed it and argued that's
fine if there is a misalignment between those components [1], which I
still think, but tbh. I also like the boxLabel more for the "Prepare
for VirtIO" checkbox, so lets use it there too and hope all are happy
again.
[0]: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062411.html
[1]: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062412.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Mapping to SATA is only one thing it does, and what we actually want
to do is preparing for VirtIO, the effects are implementation detail,
so name it after the reason not one specific step.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Avoid some global widget config to store internal state, rather use
the existing viewModel for that.
Also avoid unnecessary references and switch to a boxLabel, drop also
the tooltip, as that doesn't add much here where the effect can be
seen in the grid.
Avoid reconfiguring all grids if only the network one can have changed
due to a change of this check box value.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by adding a new checkbox and render the grid accordingly.
If unique MAC addresses are enabled, set them to undefined when getting
the values from the grid.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
and add a link to recreate the boot entries in ovmf
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: break up String.format to avoid overly long line ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we have to set it to '__default__' if we didn't get one from the API
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: fix-up eslint warning ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it seems on esxi, most windows vms with uefi are automatically
configured with an lsi scsi controller, which we can't currently support
(ovmf driver issue) so automatically activate the sata mapping + virtio
preparation in this case
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
while most of our 'windiows' ostypes start with 'win' not all of them do
(wxp, wvista), so just shorten the condition to 'starts with `w`', this
covers all our windows ostypes, while not including others.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Use the default value of the field also as start value in the
viewModel, as other wise the two-way binding can cause the empty
string to be set to the field's value, not vice-versa.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While it was required before commit ca9dce9e8 ("ui: guest import:
rework windows virtio-scsi preparation") to avoid making this crowded,
after that commit we already got the top-padding from the columnT
here, so no need for adding extra padding to that.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
On ESXi one can have at max 768 vCPUs and that over maximal 128
sockets. Further, by default ESXi will favor adding single-cpu
sockets, so if one just enters "give me 8 vCPUs", it will be 8
single-core sockets.
As we only supported up to 4 sockets in the web UI, which caused this
field to show up as invalid on initial load for such VMs, which is not
nice.
Having that many sockets is rather odd, so for us it doesn't make
sense to allow more than the ESXi limit that, but having more vCPUs
might make sense, so allow up to 1024 for that for now.
Note that QEMU and our API backend doesn't really cares, the kernels
NR_MAX_CPU is the limit there. Albeit it is questionable if using more
vCPU threads as there are host threads has some sense in any setup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of having a separate iso selector that shows with an enabled
checkbox, just add a CDROM drive when windows is selected and there is
no such drive available yet.
The idea here is that the VM's OS is already fully set up, so a single
CDROM drive is enough to be used for installing VirtIO drivers, unlike
the VM create case, where the first one is already used for the
installation medium.
Also, rename the 'map to sata' checkbox to 'prepare for virtio-scsi'
that also changes the scsi controller to virtio-scsi-single
Additionally, change the positioning of the checkbox/scsihw selector
to be below the disk grid
With that we then only disable prepare-for-virtio checkbox for
non-windows OS types, as the scsi controller on the right looks like
it hangs in the air without any field on the left otherwise.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: rework commit message, squash in some fixes ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
similar to what we have in the wizard.
in the case we cannot find a suitable slot (ide0/2, sata0-6), we
continue, but print a warning into the javascript log
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this is useful when wanting to change to virtioscsi for windows vms,
since we cannot have multiple different scsi controllers.
we assume here that all assigned sata disks/cds have a continuous range,
so sata0, sata1, etc. without any holes
with that assumption, we can use the maximum sata index and simply put
the scsi ones after that.
when there are too many disks to map correctly to sata, show a warning
with the disk id that contains a tooltip.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Use a similar text than we do for the live-restore warning and make it
use the pmx-hint CSS class.
Note that the CSS class order is important here as ExtJS automatically
uses the last one in the list here to add a XYZ-default and XYZ-after
class, so if the hint one is the last in the string, then layout gets
broken.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
From the footer-bar, so make it a bit more apparent, and also to add
the 'Experimental' text to it.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of putting all options on a single panel, split into 'general'
and 'advanced'
we move all disk/cd/network related grids to the advanced tab, and
introduce a 'default storage' and 'default bridge' selector to the
general tab.
this way, one can import very quickly when the default are fine or
when only the storage/bridge should change, but can still set the
storage/bridges etc. very fine grained.
also we have the possibility to extend the window in the future with
more tabs.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Add a new 'import' panel for storages supporting the 'import'
content type that shows a list of configs to import.
When opening the wizard, we query the meta info from the new
import-metadata API endpoint, and pre-fill the fields and shows
potential warnings or things to watch out for, returned by the API.
For disks and networks we allow to select which one to use and which
storage/bridge to import to.
Additionally, users can opt-in to a live-import, where the VM is
immediately started and storage requests are fetched from the target
on demand while importing the rest in the background.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: some fixes, clean-ups and commit message rewording ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
