New Proxmox VE 1.8 ISO with latest packages

martin

Proxmox Staff Member
Staff member
Apr 28, 2005
756
2,014
263
We just released an updated Proxmox VE 1.8 ISO image including our stable packages, especially our latest 2.6.32 Kernel with aacraid module 1.1-7[28000].

Release notes:
http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_1.8
__________________
Best regards,
Martin Maurer
 
Last edited by a moderator:
I've just attempted to install the above latest ISO using the following:

qemu-img create -f qcow2 -o size=30G hydrogen.qcow2
kvm -m 2048 -boot d -cdrom proxmox-ve_1.8-6070-5.iso -hda hydrogen.qcow2

After 3 failed installs I found that the md5sum was bad.

The reason I'm writing this though is because of the way in which the installer failed. It's a one-way train, the installer. It gives RMS' lovely EULA of Freedom to get our hopes up, then dashes them on the rocks with a zero-choice installer which, when it fails, offers "Press Alt-2" to see more information about the failure, but that has no effect. The only real option is to reboot without ever knowing what went wrong. There's no escape.

Being a long-term Linux user, I know lilo and I tried tab, found the debug mode, and managed to find out that tar was dying because of a deflation error due to the ISO being corrupt. Maybe the installer behaves better when it's not corrupt... but from what I could see, that doesn't seem likely.

In an hour I'll have a fresh download with cURL done, and if that manages to pass md5 muster I'll try installing it. if not, I'll come back and ask again...
 
Last edited:
Up and running. To connect from the real world I exported port 443 using:
ssh -R 443:localhost:443 192.168.1.121

Then fired up proxmox web interface using:
firefox https://localhost

Now to see if this software can do what I need it to. =)
Hi,
i'm right, that you install PVE inside kvm?
PVE is designed to run on bare metal. Inside a virtualization you don't have kvm-support (only with nested kvm - but this is not well tested and not fast).

For a first look it's ok, but then you should run PVE on a dedicated machine.

Udo
 
... why no direct download link? We are Linux users after all, we like our reliable download tools...

bit-torrent and http downloads are reliable, so yes it would be possible to offer 100 ways but it make sense to force distributed downloads to have the ISO delivered to users as fast as possible. so go primarily for bit-torrent. and just check your downloads (md5) as this should be mandatory.

if you want to use wget, just do it - as you are an "experienced" linux user you should be able to do it:

Code:
wget -O proxmox-ve_1.8-6070-5.iso http://www.proxmox.com/downloads/proxmox-ve/iso-images/89-proxmox-ve-1/download
http://www.proxmox.com/downloads/proxmox-ve/iso-images/89-proxmox-ve-1/download
 
tom: actually, the http download failed 3 times consecutively: once with firefox's own downloader, once with wget (done as above) and once with cURL, all giving the same bad md5sum.

I was confused about the download button. Turns out it is actually a direct link after all. The URL doesn't look right in the status bar because it doesn't end in something which sounds like an ISO download, but I'm happy to admit I was wrong.

You might want to check that the file on the server is not corrupt. The odds of me getting the wrong md5sum on the same download 3 times with 3 different tools and the problem being at my end are vanishingly small.
 
Yeah, I am evaluating it for installation on bare metal. I am currently running it on an AMD quad-core under KVM with Ubuntu 10.04, and I have the nested hosting turned off for now. I'm more interested in the OpenVZ containers at the moment. So far it is working as expected, which is a very pleasant surprise. Often one sees OSS projects make wild claims about their functionality and it turns out to be half implemented and quite buggy. Proxmox is very professioal in appearance and so far not only is it bug free, but a joy to use. <thumbsup />
 
Last edited:
tom: actually, the http download failed 3 times consecutively: once with firefox's own downloader, once with wget (done as above) and once with cURL, all giving the same bad md5sum.

The files on the proxmox server have correct checksum.
 
Yes, I got a good md5sum downloading from the http server today too.

I found one bug in Proxmox's 1.8's interface on the new distro:

When creating an OpenVZ container with vmid 5100 it attempted to create one instead with vmid 0, which failed.

It gave a nice verbose error:

/usr/bin/pvectl vzcreate 0 --disk 4 --ostemplate local:vztmpl/centos-5-standard_5.6-1_i386.tar.gz --rootpasswd $1$VAwI71bZ$lBGBJ/FCr/w5Btnm79Hhu. --hostname sv6100.high5systems.net --nameserver 192.168.100.1 --nameserver 192.168.2.121 --searchdomain high5systems.net --onboot yes --ipset 192.168.100.6 --swap 512 --mem 512 --cpus 1
VE 0 already exists
unable to apply VM settings -

I repeated the steps and it gave me the same error, so I went to the commandline and created it manually, which worked fine.

I had the same problem when I went to create the next VM via the web interface and again no problem at the shell.

After dist-upgrading my VMs and rebooting the host node to get clean KSM stats I was able to create another VPS without issue, so it's not easy to reproduce.
 
Last edited:
VMID below 100 are not allowed (reserved by OpenVZ). the upcoming new GUI does checks to prevent the issue.
 
To save confusion, yes I am talking about KSM with OpenVZ containers with Proxmox. This is the case because I am running Proxmox itself in KVM.

The shared pages with my app loaded are quite a large percentage of memory - about 70% of memory is being shared, which was a real shock. This leads me to believe that KVM could be a better solution than OpenVZ for my app. Next test is checking memory use with mount --bind to share the /usr /lib etc directories of the containers.

[Edit: waste of time, it breaks quota support]
 
Last edited:
VMID below 100 are not allowed (reserved by OpenVZ). the upcoming new GUI does checks to prevent the issue.

That's great Tom, but I had no intention of trying to create a VMID less than 1000.

After trying about 50 new containers to try to reproduce the problem I hit the down arrow to see my completion history and I saw that I had entered sv4100 as the VMID instead of 4100, and sv5100 for the next one, which was the cause of the two failures.

If you could get the devs to add validation to the form to check that people are entering not only numbers greater than 99 but also numeric to start with, lol... that might save them the same problem I had.
 
Last edited:
I just re-checked the new GUI and yes, for VMID only number greater 100 are allowed.