Proxmox 4 HA VM Freeze State

The "virtual node" will run on a separate hypervisor on a NAS (phpvbox on x86_64). It will just be there for the quorum, that's why I have to take care no VM will migrate on it (inception syndrome ...).
 
Ok thanks, got the point (fencing) !
Can I add a 3rd "virtual node" (installed on a VM hosted on one NAS for instance) ? And add it to the cluster together with the 2 physical nodes and then make sure that no VM will migrate on it ?


Yes. Look on my backup cluster:

Nodes acn1 and acn2 - the real servers:

Servers.png

Node acn3 is VM on other cluster. Node acn3 - for quorum only. On node acn3 no ruining VM's.

cluster.png

For VMs on this cluster I created HA group included nodes acn1 and acn2 only:

group.png

and include my VMs in this group:

vms.png

Now my VMs (in failure case) will automatically migrate between acn1 and acn2 and never to node 3.

--
Best regards,
Gosha
 
Last edited:
Hi Gosha. That's exactly what I did yesterday after posting on this thread. I've added a 3rd "virtual node" on the cluster and created a PHYS group on the 2 physical nodes and bound the VMs on this group :)

But now I have another issue with watchdog-mux and pve-ha-lrm services failing on one of the physical nodes, so I'm not advanced ...

Cheers.
 
Is this patch going to be supplied at some point. This is something we are still waiting on and could really use.

Was there any ever update to this? I am working on the finishing touches to an 8 node Cluster and was testing HA. If I execute a shutdown or reboot it goes into the "freeze" state, found this thread trying to troubleshoot it. A shutdown/reboot does not initiate a failover/switch of nodes, but if I do a power off via ILO it does. Anyway to change this behavior?
 
  • Like
Reactions: AlexLup
A shutdown/reboot does not initiate a failover/switch of nodes, but if I do a power off via ILO it does.

This is a manual action, and thus you are aware that the node shuts down. So if you want, you can migrate all VMs before you shut the node down.
 
This is a manual action, and thus you are aware that the node shuts down. So if you want, you can migrate all VMs before you shut the node down.

Which is a pain and in alot of situations your users would prefer the option of them being migrated. I really don't understand why you guys don't just add this as an option, its been requested enough times now and it really does make alot of sense. I get your guys reasoning, but it would be great if you would take your users input as well.
 
  • Like
Reactions: AlexLup
I get your guys reasoning, but it would be great if you would take your users input as well.

I see that you want this behavior, but from my point of view this makes things much more complex, and is most time not what
an user wants (because it result in long delays to shutdown a node). Please not that migrating all VM can take a very long time and produces high network traffic.
 
I see that you want this behavior, but from my point of view this makes things much more complex, and is most time not what
an user wants (because it result in long delays to shutdown a node). Please not that migrating all VM can take a very long time and produces high network traffic.

Why not just allow the user to make that decision them selves? If they feel its the better decision/result for their enviroment, then they should be able to make that decision. There is a reason why this thread has a number of people asking for the same thing as me.

I see your point on the long delay of a shutdown, but in some environments, migrating 100 VM's just isn't reasonable and waiting for a host to reboot (which can take 10-15 minutes on some older IBM/HP hosts) isn't reasonable either. I would much rather, do my host reboot and know the VM's are getting started on other hosts.

Add the option, let the user make the decision, I really don't see any downside here.
 
This is a manual action, and thus you are aware that the node shuts down. So if you want, you can migrate all VMs before you shut the node down.

Yes, I understand that and this thread detailed that out very well. However, that is the entire point of my post. Was there ever an update to make a toggle for this to be a user decision? I find the current approach to be very counterproductive for how I would leverage the environment and see no reason why there could not be a simple toggle that gave us the ability to decide which approach to take. This should be easy to implement and would be a good compromise for this issue.

EDIT: Is there a way for me to edit code on the backend that could alter this behavior? Maybe a plugin of sorts?
 
Why not just allow the user to make that decision them selves? If they feel its the better decision/result for their enviroment, then they should be able to make that decision.

You are already free to implement what you need. Just send patches ...
 
If I was a programmer I would have done that years ago.

I guess a customer with alot of subscriptions just isn't good enough.

Sigh! I do not implement it because I think it is dangerous and error prone. And I do not think it
is just a few lines of codes...

We already spent much time to implement the current shutdown/restart behavior, and
I think the current solution is not that bad. I guess you are aware that shutdown and
restart behave completely different?

Shutdown: Stop VM. HA will move VMs to other nodes.
Restart: Stop and freeze VMs. HA will not move VMs. Instead, they will be restarted when the node comes up again.
 
Sigh! I do not implement it because I think it is dangerous and error prone. And I do not think it
is just a few lines of codes...

We already spent much time to implement the current shutdown/restart behavior, and
I think the current solution is not that bad. I guess you are aware that shutdown and
restart behave completely different?

Shutdown: Stop VM. HA will move VMs to other nodes.
Restart: Stop and freeze VMs. HA will not move VMs. Instead, they will be restarted when the node comes up again.

I honestly feel these are decisions which should be left up to the Administrator. Similar to the decision of using SSH on live migration, you also felt that was insecure, but ultimately it should be left up to us to make that type of decision based on our enviroment.

I appreciate more input than previous responses and gives me a better idea on why you are reluctant to add it back in, but as you can see, this thread keeps getting brought back from the dead over and over. I have a feeling its going to continue happening simply because this is a feature your users are asking for.
 
  • Like
Reactions: AlexLup
An option at VM level like "Migrate on shutdown/reboot = yes/no" should be great. Set it to "no" by default.
 
I honestly feel these are decisions which should be left up to the Administrator. Similar to the decision of using SSH on live migration, you also felt that was insecure, but ultimately it should be left up to us to make that type of decision based on our environment.

Sorry, but it seems that I simply do not understand what you want exactly? We already have insecure live migrations, and we also have migrate on shutdown. You can already do those things!
 
Sorry, but it seems that I simply do not understand what you want exactly? We already have insecure live migrations, and we also have migrate on shutdown. You can already do those things!

I am comparing the situation. You guys made the decision to force ssh live migration a long time ago, I pushed back and said it should be left for the Administrator to make that decision. You guys added a option for insecure migration and everyone was happy (Which I do greatly appreciate). Very similar situation.

I just don't see the downside of giving us this option and making all your end users happy and content.
 
An option at VM level like "Migrate on shutdown/reboot = yes/no" should be great. Set it to "no" by default.

Again, you already have that choice. If you do a shutdown/poweroff, VMs will migrate by default. If you do a 'reboot', VMs will stay on same node.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!