Proxmox VE 3.0 RC1 released!
- Thread starter martin
- Start date
No, not really ;-) Seems a bug in the new server, which always compress the response.
To workaround, use the '--compressed' flag of curl.
S
Spenzer4Hire
Guest
Thanks juaserco. This works for me as well. The only issue is I have to run it once each time I boot the server. My iSCSI target is the first VM to boot, so iSCSI target is not immediately available to the host. Not sure if that's related... Had no issues with this setup on 2.3.
I had same issue -to fix it go into your iscsi config and change startup to automatic instead of manual
2.3 worked with manual
- - - Updated - - -
To get iscsi to work change the startup to automatic instead of manual - I had this problem when first upgraded
S
Spenzer4Hire
Guest
Hi ejc, thanks for the tip. I edited /etc/iscsi/iscsid.conf and changed node.startup to automatic. This didn't seem to have any effect (may only affect newly-created iSCSI connections). I then went into each config file (/etc/iscsi/nodes/<TARGET>/<PORTAL>/default) and set node.startup to automatic. Now when Proxmox boots it attemps to open all of the iSCSI connections at once, before any of the VMs boot. After the timeout Proxmox continues starting up, then launches my first VM (the iSCSI target). As the subsequent VMs try to start they get the error: iscsiadm: No active sessions. TASK ERROR: command '/usr/bin/iscsiadm --mode session' failed: exit code 21
On Proxmox 2.3 it was as if it tried the iSCSI connections on demand when the VMs were started.
The previously-mentioned workaround (iscsiadm -m node --portal <ip>:3260 -T "<target>" -l) still gets me up and running.
Any other ideas? Thanks again!
Hi, I can reproduce it here too. I'll do tests tomorrow to see where is the problem.
Ok, I have found the iscsi bug, I have send a patch to the dev mailing list, should be ok for the RC2
As far as I know, changing startup to automatic fixed it for me. It's not the best way of doing it since it opens ALL the iscsi connections. However, there are some other uses for this.
The bigger problem is that multipath no longer works ...
Hi, I upgraded my Squeez to Proxmox 3.0. The machine now keeps booting into Debian's default kernel (3.2). Not sure how to fix this (I already tried playing with Grub but to no avail). Any recommendations?
no, it'won't come in 3.0
see this post http://forum.proxmox.com/threads/13758-Proxmox-and-spice
Marco
How long will PVE stay with the 2.6 kernel? Are there already "fixed" dates for a 3.2 kernel?
Not that I'm about to switch all VMs immediately to wheezy+3.2 release, but it would be nice to know if this update will come e.g. in the next 3 months or not before 2014.
Not that I'm about to switch all VMs immediately to wheezy+3.2 release, but it would be nice to know if this update will come e.g. in the next 3 months or not before 2014.
Note that proxmox use redhat rhel6 2.6.32 kernel with a lot of things backported from more recents kernel (3.4 ,3.5,....).
So next big update should be rhel7 kernel (based on 3.8 kernel I think), but I think it will be release at the end of 2013.
you can safely remove debian kernel:
#apt-get remove linux-image*
and verify that pve-kernel is installed:
#dpkg -l|grep pve-kernel
Nope, didn't work for me
And this is with RC2/current wheezy installation/upgrade instructionsMacOSX 10.8.3
FireFox 20.0, and the current 21.0 (Safari do work though)
I have to mention: If I do a ISO installation, it just works, but doing a Wheezzy isntalaltin FOLLOWED by installing Proxmox-pve, I get this problem.
Check this highlighted part of the log snippet:
May 21 07:31:56 skyhost pveproxy[3368]: problem with client 192.168.5.123; rsa_padding_check_pkcs1_type_1: block type is not 01
May 21 07:31:56 skyhost pveproxy[3368]: WARNING: Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/PVE/HTTPServer.pm line 167.
May 21 07:31:56 skyhost pveproxy[3368]: WARNING: Can't call method "push_write" on an undefined value at /usr/share/perl5/PVE/HTTPServer.pm line 214.
This looks like an SSL issue ;(
Last edited: