Proxmox VE 7.3 released!
- Thread starter martin
- Start date
I think what they were asking about, at leadt that's what I am asking for, is the possibility to essentially activate the shutdown migrate policy without shutting down.
I want to be able to set the node to maintenance, having the LRM mark itself as unavailable so the (HA) VMs get evacuated. Then I can work on the node still running, like upgrade, change networking, do anything else that requires the node to be running.
When done, I can unmark the node as being in maintenance and (in the future, with issue 2115 perhaps), VMs can rebalance back to the node, and I can continue with the next node.
OK but is it not possible to enforce this ? It is confusing to not see a feature (cpu affinity is the reason I am asking) even after a restart.
Yes, if you tell the browser to turn off caching completely, which naturally makes the interface less efficient. Note that we try already a lot to push the browsers in the right directions, like including the version as request query parameter in the index to make it change on updates and thus request a different URL than before, but browsers are beasts and not always considerate ones. We're checking periodically if there's something better, but still reasonable to do; if we find something we'll improve it.
That can indeed be implemented now without all too much trouble (knocks wood) but also independent of the new CRS, which will give just better node targets for balancing out.
Last edited:
That would be very useful! Is there already on the radar or even a feature request in Bugzilla or should someone (me) add it?
There's one for the general non-HA-thing, but I don't think there's one for enabling the for shutdown already existing mechanism on runtime, so yeah please add an enhancement request and maybe mention this thread to avoid that a colleague directly merges it as duplicate with the non-HA one.
Quick newbie question, what's the best way to upgrade a live (single) system? Should I shutdown all the VMs first - upgrade - then reboot, or would it be fine to upgrade running VMs live, and then reboot when later on (during night for example)?
It normally is fine to upgrade while the VMs keep running.
Note though that you would only need to reboot the node to boot up any updated kernel (e.g., check
pveversion -v to see if there's a newer kernel in the list than the running one mentioned on top), otherwise that isn't necessary either.
Datacenter -> Options -> Edit: Tag Style -> Color Overrides
to be done in the GUI, the global serach at the top (
CTRL + SHIFT + F) allows one to search for tags too already though, should cover a lot of use cases in the mean time.
Last edited:
Ok cool.
That's really a missing feature, as sometime you need to do tuning or network change, and you want to set the node in maintenance without shutdown it.
It does. Thank you!
This is a Linux 2.6 OS, and my Machine type is set to Default/i440fx (Latest). I think that means this one is up to date and I don't have to recreate it to get the new hot plug USB?
What's the easiest way to test if I have the new USB functionality enabled?
Does anyone experience to be logged out of the web-interface of this new version after a few minutes with this message "permission denied - invalid PVE ticke (401)". Because I do, and I can't seem to find a setting for timeout like this. Is this a bug?
Add a SPICE USB to that VM bia its Hardware tab when it's running. That is just a virtual port for ise with the spice virt viewer, so it avoids passing through an actual (possibly in use) device or port. If it doesn't stays pending (orange font) it got hot plugged.
Can you try clearing the browser cache an retry? Also any third party packages installed that mess with the system?
It worked! I'm going to assume I can leave all this alone and call it working, then.
Thanks!
Hi
I've tried it in Firefox and also tried using "Incognito-mode" on Chrome. Same result, I'm kicked out after a few minutes.
And I have absolutely NO 3rd-party software on this system. I've installed some Debian packages like deborphan, members, and ethtool, but I can't imagine them interfering with this.
This is a cluster test-system that I have for exactly this kind of thing, and it's configured in precisely the same way as the production-system.
I'll be glad to do some digging around to solve this. And it might have something to do with my setup. Especially if nobody else is experiencing this.
And I have licenses for both systems.
please check
- that all nodes in the cluster have their clocks synchronized with NTP and agree on the current time
- the timestamp of /etc/pve/authkey*, it should be within the last 24h
-- if it is further in the past your cluster is likely not quorate! check logs of corosync and pve-cluster and output of pvecm status
-- if it is in the future, one of your nodes likely had its clock set wrong, a simple
touch /etc/pve/authkey.* should reset it and fix the problem