Survey: Proxmox VE Kernel with or without OpenVZ?

[tom]

Thanks for your quick reply.

I do not see testing on 2.6.24 there, is it safe for me to assume that going forward we will see 2.6.18 (for openvz and kvm) and 2.6.32 (for kvm) replacing 2.6.24 altogether? So we only have 2 kernels for Proxmox left?

depends on the test results but this the favorite plan.

 

[martin]

The 2.6.18 kernel does not support ocfs2.

uranus:~# uname -a
Linux uranus 2.6.18-1-pve #1 SMP Mon Dec 21 10:03:07 CET 2009 x86_64 GNU/Linux
uranus:~# gunzip -c /proc/config.gz |grep OCFS2
# CONFIG_OCFS2_FS is not set

thanks, I confirm and we will add it.

 

[nka]

I currently using Virtuozzo and I may move to Proxmox (+ donation), but if you remove OpenVZ, I think I'll cry.

More seriously, I'll be testing KVM, but I'm pretty much sure that OpenVZ Container are much faster and less ressources hog than KVM (linux speaking)

 

[pschroth]

OpenVZ is vital for us. The servers we have are not to old, but lack virtualization extensions on there cpu's. Whem there is time to upgrade then of course the demand for openvz will go away.

 

[dietmar]

The 2.6.18 kernel does not support ocfs2.

Just uploaded a fixed 2.6.18 kernel including ocfs2 - please can you test?

 

[François MASSON]

The new 2.6.18 kernel boot just fine and do join the ocfs2 cluster.

I will test it on hardware with incompatible bnx2 this weekend.

Edit :
I don't known if this is kernel related, but I can't boot with pxe on this 2.6.18 kernel, while it run flawlessy on the 2.6.32 kernel

uranus:~# qm start 113
No valid PXE rom found for network device
start failed: command '/usr/bin/kvm -monitor unix:/var/run/qemu-server/113.mon,server,nowait -vnc unix:/var/run/qemu-server/113.vnc,password -pidfile /var/run/qemu-server/113.pid -daemonize -usbdevice tablet -name Test-XP2 -smp 1 -boot nc -vga cirrus -tdf -localtime -rtc-td-hack -k fr -drive file=/var/lib/vm/iso/virtiokvm-all.iso,if=ide,index=1,media=cdrom -drive file=/var/lib/vm/images/113/vm-113-disk-1.raw,if=ide,index=0,boot=on -m 512 -net tap,vlan=0,ifname=vmtab113i0,script=/var/lib/qemu-server/bridge-vlan -net nic,vlan=0,model=rtl8139,macaddr=AA:9E:6A:F4:49:98 -id 113 -cpuunits 1000' failed with exit code 1
uranus:~# pveversion -v
pve-manager: 1.5-4 (pve-manager/1.5/4618)
running kernel: 2.6.18-1-pve
proxmox-ve-2.6.18: 1.5-4
pve-kernel-2.6.18-1-pve: 2.6.18-4
qemu-server: 1.1-11
pve-firmware: 1.0-3
libpve-storage-perl: 1.0-6
vncterm: 0.9-2
vzctl: 3.0.23-1pve5
vzdump: 1.2-5
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-4

 

[gordan]

I haven't heard of any.

I can imagine one (which doesn't require the binaries to be modified) using existing kernel infrastructure though: use in-kernel binfmt_misc to execute every binary in the guest with a special "interpreter".

It would use additional system resources though and would need installing additional software in guests.
And would likely fail for some more complicated programs.

Also, such software does not exist.

Unless you've heard of other workarounds, or have different ideas.

Sorry for necroposting, but I just stumbled upon this thread.

You're not thinking about this in the right way.
There are two things to consider.

1) Something that really needs to be looked into is something like the hashify feature from VServer. It finds all identical files across guests and replaces them with hard links. This makes shared libraries all mmap() to the same memory so you end up with all DLLs sharing the memory and massively reducing the memory footprint (and disk footprint, too, but that wasn't the point here). Even without leveraging KSM, this would yield a substantial memory saving with no overheads.

2) You could hook KSM/madvise via LD_PRELOAD. Have a look at this thread here from the KVM mailing list:
http://www.spinics.net/lists/kvm/msg36193.html
All it requires is a volunteer to write such a thing.

 

[Lantizia]

Since there is now a KVM only kernel... and an OpenVZ/KVM kernel....

Perhaps the Proxmox team would like to take the efforts found here to make a OpenVZ only kernel?

It would be cool for the installation disc to offer 4 choices...
32-bit OpenVZ kernel
64-bit OpenVZ kernel
64-bit OpenVZ/KVM kernel
64-bit KVM kernel

As this will allow even more people to use the product on less advanced hardware... and more profit for Proxmox themselves as it will allow more people to run their Mail gateway on the PVE platform on systems without Intel-V support.

 

[/dev/null]

It would be cool for the installation disc to offer 4 choices...
32-bit OpenVZ kernel
64-bit OpenVZ kernel
64-bit OpenVZ/KVM kernel
64-bit KVM kernel

I think the overhead of supporting this, would be too much to handle.

 

[Lantizia]

I think the overhead of supporting this, would be too much to handle.

Well lets see...
32-bit OpenVZ kernel
--> Community has already created this
64-bit OpenVZ kernel
--> A tiny adjustment of the above
64-bit OpenVZ/KVM kernel
--> Already exists
64-bit KVM kernel
--> Already exists

At the end of the day it's just slightly different make commands - choosing to unselect something from compiling.
The effort to get 4 kernels is incredibly minimal for the Proxmox VE team...

And in terms of support... well we already have to check what kernel they use now already - no different.

But the rewards for their platform being available on even more hardware would be great.

 

[dietmar]

At the end of the day it's just slightly different make commands - choosing to unselect something from compiling.
The effort to get 4 kernels is incredibly minimal for the Proxmox VE team...

The efforts to compile, test, support and maintain the kernels is much to big now. I have to reject anything which increase that efforts.

But anyone with enough spare time can compile and provide other kernels.

 

[Lantizia]

The efforts to compile, test, support and maintain the kernels is much to big now. I have to reject anything which increase that efforts.

But anyone with enough spare time can compile and provide other kernels.

We'll it has already been demonstrated that people can and have developed other kernels, we have already seen the i386 OpenVZ only kernel in the repository.

The question is will you let those people become a part of the team so their efforts can be included on the ISO itself? Also obviously although the Proxmox VE GUI can be KVM-only aware, it would also need to be OpenVZ-only aware too... a slight tweak.

 

[tom]

We'll it has already been demonstrated that people can and have developed other kernels, we have already seen the i386 OpenVZ only kernel in the repository.

these i386 packages are a good example for a one shot kernel - not supported, no updates, some core features are not working (KVM). but yes, only useful for a small minority, in a short run.

The question is will you let those people become a part of the team so their efforts can be included on the ISO itself? Also obviously although the Proxmox VE GUI can be KVM-only aware, it would also need to be OpenVZ-only aware too... a slight tweak.

all developers can join our team and can work with us, just contact us directly. but we will not include i386 as its a dead end technology already (for virtualization hosts).

 

[SirLouen]

I believe that proxmox with no openvz is not proxmox... you just can have KVM with any other dist

What about this http://wiki.openvz.org/Download/kernel/2.6.32/2.6.32-budarin.1 ??

 

[yatesco]

I believe that proxmox with no openvz is not proxmox...

Well.....I personally don't use OpenVZ at all for any of my 50+ VMs - they are all KVM. The reason I don't use another product is:

- backup solution for proxmox is pretty nice
- ease of configuring infrastructure (setting up SAN and VLANs etc.)
- access to administration via the web is perfect for me and my distributed team
- access to a web based console to each VM - see previous point

before proxmox I did everything using Ubuntu by command line....not that much fun. There is the libvirt GUI (cannot remember the name) developed by Fedora/RedHat but it really didn't want to work over a WAN that well. It was just very very slow.

But I get your point. If OpenVZ:

- worked across a cluster (i.e. it could be stored on the SAN as oppose to local disks)
- didn't require you to sacrifice 3 white chickens that are no more than 2 weeks old on a moonless night on Tuesday evenings between 8.03 and 8.06 PM wearing one wellington boot and one yellow sock and one white sock in order to get Java working

then I would be in a very different place - OpenVZ rocks (and I am not sure which of the above are inherently OpenVZ issues and which are Proxmox's build of OpenVZ ) but for now, Proxmox and only KVM is great for me.

 

[SirLouen]

then I would be in a very different place - OpenVZ rocks (and I am not sure which of the above are inherently OpenVZ issues and which are Proxmox's build of OpenVZ ) but for now, Proxmox and only KVM is great for me.

Are you virtualizing even then linux machines with KVM? Then is like a KVM solution, is pretty powerful, but then I might be considering maybe the power of the ultra hardware recognition possibilities of other solutions

 

[yatesco]

Are you virtualizing even then linux machines with KVM? Then is like a KVM solution, is pretty powerful, but then I might be considering maybe the power of the ultra hardware recognition possibilities of other solutions

Yep - about 45 VMs are Ubuntu server. I only use HP DL380 G6 servers which are recognised fine under Debian/Proxmox.

 

[SirLouen]

Yep - about 45 VMs are Ubuntu server. I only use HP DL380 G6 servers which are recognised fine under Debian/Proxmox.

Definitely I muss give it a try... specially if KSM works with linux vms well

 

[jmjosebest]

I vote for more performance in qemu

 

[ozgurerdogan]

I think with no linux vm support = no openvz, proxmox can not be called as enterprise level or cloud computing system. For me (as a hosting provider) best would be, supporting both with; 1) a users choice or 2) supporting both with one kernel. I guess OpenVz vms are more than KVM vms, at least in hosting environments. Also clustering will be worthless with only KVM support.

So I will go for voting Keep old Kernel with OpenVZ support (2.6.24).
I read many articles about esxi vs proxmox comparisons which usually express proxmox has many reasonable options to be selected. I am afraid with this decision, proxmox may fail