Updates for Proxmox VE 2.2

The bug #278 may be not related to my issue. I face slow NIC issue either using Realtek, e1000 or Virtio, but after upgrade to 2.2-30 I got very fast NIC, nearly 70 Mbps (my Switch is 100 Mbps).

Unfortunately they are not related. I've been following a mailing list for qemu that dietmar has been discussing this issue in. This isn't a Proxmox related issue. There is no fix yet, just a workaround, but the work around unfortunately involves disabling vhost which triggers the issue.
 
I have a problem with the latest update 2.2.31.
I created a separate topic about this but no one answered.
May be someone can answer here...

I updated all my proxmox ve hosts in a cluster two days ago from 2.1 to 2.2.
After the update one of my nodes begun to fall into general protection fault right or after few minutes after boot.
Here is a screen
http://s18.postimage.org/ew7hvrrg9/image.jpg
The two other nodes of the cluster seem to be OK.
I tried to reinstall the proxmox ve 2.2 from the CD. Right after the install it seemed to be OK. I ran "apt-get update" and "apt-get dist-upgrade".
Then I rebooted and tried to ssh to the host. And again the host got into general protection fault.
What to do?
Should I install proxmox ve from the CD and leave it without update? May be I should wait for another (more stable update)?
Then another question: will I be able to add that node ( 2.2 from CD without the latest update) to my cluster where two other nodes were already updated to the latest version?
 
Last edited:
Are all nodes identical hardware and with exactly the same BIOS version and BIOS configuration?

No, all of them are different. These are different models of HP server blades in one bay with shared SAS storage HP MSA 2012 SA

Problem server is HP ProLiant BL460c G6

Other (working) servers in the cluster are:
1) HP ProLiant BL620c G7
2) HP ProLiant BL460c G7
 
we once had a similar issue - when Proxmox moved to the RHEL kernel, we had a node which locked up randomly (afair with a panic). Using a stress test tool, we were able to reproduce this - and also that kernel versions before that new one did not have the problem.
At the end it turned out that it was indeed hardware related. We got a new (same type) mainboard, new (same types) cpus, and the problem was 100% gone.
So yes, a kernel *could* make the difference, and "trigger" an hardware defect...
 
we once had a similar issue - when Proxmox moved to the RHEL kernel, we had a node which locked up randomly (afair with a panic). Using a stress test tool, we were able to reproduce this - and also that kernel versions before that new one did not have the problem.
At the end it turned out that it was indeed hardware related. We got a new (same type) mainboard, new (same types) cpus, and the problem was 100% gone.
So yes, a kernel *could* make the difference, and "trigger" an hardware defect...

Hmm. As for me I think this looks rather like a kernel defect than a hardware defect. (The server worked well alone and in the cluster with version 1.8, 1.9, 2.0, and 2.1)
 

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!