especially on chromium based browser (e.g. chrome, edge) it can happen,
depending on the zoom level, that the last column does not fit next to
the other columns and is moved below the other columns.
This results in an ugly looking UI and in the worst case makes it
unusable.
This can also be triggered if the monitor is set to a higher scaling /
different DPI settings. I was able to have the same problem in Edge when
setting the scaling in the windows display settings to 125% (Clone VM).
Changing the layout from columns with 0.5 width to extjs HBOXes with
flex 1 works as expected.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
so the current disk locations can be preserved even if
there are multiple local disks. And users don't have to
manually select the current storage if there is only one
local disk.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The size of VM state files and the size of unused disks not
referenced by any snapshot is not saved in the VM configuration,
so it's not available here either.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
All local disks can/will be migrated if not for a reason we don't
know about yet at this stage. The disks we get from the API call as
'local_disks' are either referenced by the config or by snapshots in
the config (which was not checked for and the reason one could run
into the 'else if' branch).
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As the cloudinit disk itself does not get copied on an offline
migration, just the config, there's no conflict. Ignore the local
cloudinit disk on offline migration. Also adds a useful message when
trying to live migrate with a local cloudinit disk.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Added to make use of [0] and because it does make sense for non HA vm's
as well, in accordance with #2241.
[0] pve-ha-manager: 6e8b0c225405da9472f56fe5c94c94b204259caa
Signed-off-by: Tim Marx <t.marx@proxmox.com>
Like previous to commit 9706707d2f
which broke this, we have some assumptions in our gui-test/screenshot
automation which lays assumptions on certain window titles, so try to
keep them stable.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This makes the window more symmetric, and additional has the
following small advantages:
* to the left we now have static fields only, user modifiable ones
are all to the right (with shorter distance to the migrate "submit"
button here)
* if one starts the migration from the tree's context menu it may not
be really clear where the VM currently is located at, so showing
the source node can help (especially on bigger clusters with a
huge target node list)
* more symmetric
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch depends on:
qemu-server: e1f0fbf4448b374eb9a19502aee565adb5be7ec0
This patch refactors the migrate ui to incoperate the viewmodel approach
which should help if we need to add functionality in future iterations.
Additionally it is now possible to migrate with local disks.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
Proxmox.button.Help renamed the css class for the button styling, as
this class is only used rarely and the widget toolkit does not
provides a (shared) css file itself, just rename it here too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
some function are now in Proxmox.Utils instead, so we have to use that
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This checkbox had not effect whatsoever:
* if the VM was online and offline was selected, the migration would fail
with the message that the --online flag is needed for running VMs
* if the the VM was offline and online was selected, the migration would
happen offline anyway
by mistake we checked if me.vtype is 'qemu'
but the property is me.vmtype, so we would always show
restart mode
note that this error was purely cosmetic, behaviour was correct
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
for now we have to explicitely define the
onlineHelp: 'blockid'
string, so that the parser picks it up
in the future we should refactor that window, so that we define the
blockid when declaring the component
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
As we cannot migrate to the source node do not show it in the
migration window's node selector.
Fixes#1049 partly
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this also fixes the problem that the method
Ext.ComponentQuery.query() was outputting a warning
since it did not know if it should perform a lookup
for a class name or a xtype
