Thomas Lamprecht [Mon, 17 Jun 2019 10:41:16 +0000 (12:41 +0200)]
ui: migrate: add source node field and rebalance field positions
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 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.
network api : reload : don't allow openswitch at all
ifupdown2 reload can't work with openswitch until we implement
ovs.
I don't think that too much users are mixing ovs && bridge anyway.
It's possible to use ifupdown2 with ovs for ifup/down with ifupdown script,
but config need to be changed, and I don't have tested too much.
(maybe add a conflict in ifupdown2 package with openvswitch package for now)
Thomas Lamprecht [Mon, 10 Jun 2019 17:04:10 +0000 (19:04 +0200)]
gui: tree: add lock information to tooltips
This was already proposed by Dominik[0], but it was was wished for a
faster backend backing of this[1], and as with most wishes one needs
to either be content with what's there or (try) to improve it one
self.. So with the IPCC approach proposed as backing for this I'd
like to add this again. It differs from [0] a bit, first it's rebased
as parts of the tooltip stuff got already applied[2].
I use "Config locked (<LOCK>)" as text for this, as it
1. Clarifies what the lock symbol means, which is always a good thing
for tooltips
2. repeating the lock symbol here again would show the users three
lock symbols at the same time if the VM was selected in the tree
(the tree one, the VM config panel one, and this tool tip one)
this is a bit much, so don't do it.
Thomas Lamprecht [Mon, 10 Jun 2019 16:51:39 +0000 (18:51 +0200)]
api: cluster/resources: add information about guest locks
using the new get_guest_config_property helper from pve-cluster,
which allows us to get this info with relatively low overhead.
With a somewhat realistic setup of 303 guest configurations here my
API call timing changes from ~ 24 to 26 ms without this to 26 to 28
ms with this patch applied, which seems reasonable.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Christian Ebner [Tue, 11 Jun 2019 13:31:12 +0000 (15:31 +0200)]
fix #2190: Base64 encode SMBIOS value strings in order to allow more characters
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>
gui: vm: add CPU flag selector with tri-state awareness
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 92572ead6dc4e2a4475111a4c4d52be8f849d9a2) Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Wed, 5 Jun 2019 13:59:37 +0000 (15:59 +0200)]
ceph: make ceph osd create api more readable
The aim of this patch is to reorder/rework the code of the api call
so that it gets more readable
it adds comments of what/why something is done, removes
code duplication between db/wal checks/creation
There are two changes in behaviour:
* when a device is given more than once via the api,
the user gets a parameter exception for the db or wal
with the information that the explicit defined devices must be
different
* we check the usage for db/wal before the worker, so that the user
gets instant feedback if a device is already in use
(this is more for api users than for gui users, since we do those
checks there also)
Dominik Csapak [Tue, 4 Jun 2019 12:47:53 +0000 (14:47 +0200)]
gui: ceph: add ServiceList component and use it
this is an abstraction for listing Ceph Services with a few improvements:
* start/stop/restart buttons for all services (incl. icons)
* a syslog button to view the syslog of that service
* correct reloading behaviour when creating/destroying
api: ceph mgr list: check if active_name is really set
As in a situation where we /had/ a manager but destroyed it this
key's value is a empty string, and if we pass that to the WebUI we
get strange results form of a ghost MGR entry with ExtJS auto-ID
generation as name -> pretty confusing.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Tue, 4 Jun 2019 12:47:51 +0000 (14:47 +0200)]
ceph: osd: rework osd destroy to work with ceph-volume
with this, osd destruction is left to ceph-volume if the osd was created
with ceph-volume, else our old code remains mostly the same since
we want to be able to destroy upgraded osds
Dominik Csapak [Tue, 4 Jun 2019 12:47:50 +0000 (14:47 +0200)]
ceph: osd: rework creation with ceph-volume
this completely rewrites the ceph os creation api call using ceph-volume
since ceph-disk is not available anymore
breaking changes:
no filestore anymore, journal_dev -> db_dev
it is now possible to give a specific size for db/wal, default
is to read from ceph db/config and fallback is
10% of osd for block.db and 1% of osd for block.wal
the reason is that ceph-volume does not autocreate those itself
(like ceph-disk) but you have to create it yourself
if the db/wal device has an lvm on it with naming scheme 'ceph-UUID'
it uses that and creates a new lv
if we detect partitions, we create a new partition at the end
if the disk is not used at all, we create a pv/vg/lv for it
it is not possible to create osds on luminous with this api call anymore,
anyone needing this has to use ceph-disk directly
service: add restart on-failure to pveproxy and pvedaemon
This way they can cleanly exit (with a SIGTERM or systemctl stop) but
will get restarted if killed or they abort, but only for
StartLimitIntervalSec= time period with a total maximal count of
StartLimitBurst= retries.
See `man systemd.unit` for details, default are 10s total
restart retry period with at max 5 total retry counts, after that the
unit will placed in the failure state. So this is a best effort try
with no real downside.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as already announced over two months ago[0], remove the unofficial
SheepDog plugin now completely. Besides that it was never fully
supported in Proxmox VE one of its main developer and ex-maintainer
declared it as abandoned[1], and thus just let's remove it, git
allows to resurrect it any time if a wonder happens anyway.
get_cluster_service: do not always call cfs_update
This was done to ensure the nodelist, which get_node_kv uses
internally to loop over all nodes, is filled. But, everything coming
through API/CLI already has a cfs_update called so this is not
required outside from development testing calls. As we normally do
not do this for such calls, cfs_update call is a prerequisite for
such things. The better solution would be handling this internally in
get_node_kv, e.g., by checking if $clinfo->{versionn} was set once,
and if not call to cfs_update, or maybe even better, so adapt the IPC
call for a possibility to get the KV status hash for all nodes.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Tue, 4 Jun 2019 12:47:42 +0000 (14:47 +0200)]
ceph: refactor broadcast_ceph_services and get_cluster_service
and use the broadcast when a service is added/removed
we will use 'get_cluster_service' in the future when we generate a list
of services of a specific type
Thomas Lamprecht [Fri, 31 May 2019 14:33:37 +0000 (16:33 +0200)]
ceph: remove cube symbol for now, confusion with CTs
This was the exact same symbol we use for container, and as this is
_not_ CT related, and box did not make sense for the version here for
me, just remove it for now before we forget it..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Fri, 31 May 2019 13:39:48 +0000 (15:39 +0200)]
followup: make ceph version handling more flexible
ceph has a bad reputation for chaging such minor things a few times,
even during a stable release, and as here a bit more flexibillity
cost exactly nothing let's do so and accept versions with one to
arbitrary version levels
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Mon, 27 May 2019 13:49:02 +0000 (15:49 +0200)]
pveceph install: allow nautilus and use as default
We allow 'luminous' still for testing purpose, it could be also
useful if one already upgraded his cluster to PVE 6.0 / Buster but
not yet ceph and due to a incident needs to setup a new luminous node
on Buster to get healthy again. This is fabricated but not
unthinkable, as it costs nothing and isn't available for WebUI user
just keep it for now. Remove with a future point release though.
Use non-public repo for now, will be updated to testing soon.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Mon, 27 May 2019 12:13:54 +0000 (14:13 +0200)]
add cluster wide ceph api calls
add two new api calls in /cluster/ceph
status:
the same as /nodes/NODE/ceph/status, but accessible without
nodename, which we don't need, as in the hyperconverged case, all nodes
have the ceph.conf which contains the info on how to connect to the
monitors
metadata:
combines data from the cluster filesystem about the services,
as well as the 'ceph YYY metadata' info we get from ceph.
with this info we can convieniently display which services exists,
which are running and which versions they have
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-manager.git / log