Adds the same check we run in pve-cluster before joining a node to make
sure the hostname resolves to a configured IP.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
this warns the user that he cannot live migrate VMs with svm/vmx to PVE6 when
the nested parameter of the kvm module is on
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
While we nowadays can work much better with package upgrades relating
the cluster stack it still happens that a pve-cluster upgrade can
produce a false-positive 401 (auth failure) code for a currently
valid ticket, e.g., because a pmxcfs lock was requested but the
pmxcfs was currently not mounted due an upgrade triggered restart.
A frequent case for a few false positive 401 is also a cluster
creation, especially if not done over the web GUI.
Thus add a counter, which gets set to 0 on each successful login or
ticket renewal and gets increased on each 401 error. Only show the
logged out window if we get five or more 401 responses. While 5 may
sound a bit much one needs to remember that we always have quite a
few API call in flight (resource update store, stores from current
panel ...) and thus, if one got really auth denied it will still show
quite fast (1 to 5 seconds, depending on which panel is currently
opened). Further, the backend naturally does not allows to do
anything during this time, this has no security implications
whatsoever.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
a 'mon remove' does this already for us, so do not stop it
this lead to a race where we could stop the next to the last monitor
before it was removed from the cluster, leading to a state
where two monitor were needed for quorum, but only one did exist
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we need to remove an ip, ip:port or a ipvector from monhost
so use multiple regex search and replaces for this
this looks not really nice, but due to the strange format
of the line (e.g. ',' is a seperator inside and outside of a vector,
also ipv6 adresses may be surrounded with [] but so are vectors),
i found no better way
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
otherwise it is possible that multiple users create monitors at the same
time, resulting in a wrong ceph.conf and probably worse
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in nautilus, the default msgr protocol is v2, but it has to be
explicitely given to monmaptool, also we don't want to use the
monitor sections anymore so only update mon_host
ceph can cope with mixed mon_host and monitor sections, so this is
not a problem
also the ceph-create-keys part is not necessary anymore since
this is done by the monitor itself now
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by using our new 'get_services_info'
this already checks for nautilus+ style 'mon_host' key in the ceph.conf
for the ip address
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Make clear thet the 5.x is also supported and reword a bit as
"5.X/4.X/3.X/2.6" is a bit hard to read, so use "5.X - 2.6"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
normally this gets created on package installation, but could be
deleted, e.g., by a debug purge. As it costs nothing to create just
do a mkdir on it, which does not fails if it already exists..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it makes no sense to have the mon key inside the client.admin.keyring
also the order and operations did not make much sense
also create the client admin keyring when creating the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if we already have a monitor, we can try to get the public_network via
the ceph configuration database
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in a case where we cannot connect to any monitor, we did not get
any info even if we have them via the pmxcfs
so get the RADOS object in an eval, and get the info we have from the
config/pmxcfs, and set the state to unknown if we cannot query via RADOS
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we always gave one, and the only reason why it could be undef
is that we could not connect, so it makes no sense to try again
and add unecessary time to the api call
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
since we do not support creating filestore osds anymore, drop
the journal size from the config
and move the keyring from global to client
this makes it possible to omit the osd keyring path
(which was the default but got overwritten from the global section)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
with this one can see the avail/capacity columns in full even if we
have "xyz.ab GiB", i.e., the max length this can be.
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>
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)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
