list all vms with either max/host cputype or vmx/svm explicitely set
(this can only happen in the args)
give a general message if none is found at the moment (and do not warn)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
ms_bind_ipv4 is default true and osds look for both
ipv6 and ipv4 addresses in cluster network/public network
since we only allow for one network each (which must be either
ipv4 or ipv6) we disallow ipv4 if ipv6 is detected
this fixes not starting osds on an ipv6 enabled, newly-setup cluster
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when there is no 'public_network' in the config, the monitor
can only find an ip if it is given explicitly, either via commandline
(not possible with systemd) or via the ceph.conf
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Instead of marking all pve-kernel-.* packages as NeverAutoRemove we compile
a list of specific versions to keep.
This functionality is added in the proxmox-ve package (along with the config
for booting kernels with systemd-boot).
this is a short running script, so the version list can be re-used,
the chance that there where updates in between are slim and racy
anyway. IF getting the versions did not succeeded, we still retry on
every call though, simpler and ensures a warning is printed in the
caller check vicinity.
Makes script noticeable faster.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
only as a warning, since this will also trigger a Ceph health warning
and is easily recoverable.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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>