Beta packages for Proxmox VE 3.2 - pvetest
- Thread starter martin
- Start date
The current rados commands use a 'timeout' of 300s. This will be fixed in next ceph release (hopefully), so we will
use a shorter timeout when that option is available.
So were moving from Java (which is a pain) that runs on most OS'es, to Spice, which only runs on 2? Should have gone with novnc that runs on everything and doesnt require some third party client. 
Also, whats the advantage to your new kernel if openvz support isnt available in it? Why not just use the newest debian vanilla kernel?
Lastly, thanks for new ceph integration and improvements. Really looking forward to testing that out. What version of ceph is currently included/supported and will the upcoming Firefly release be supported? Its a huge improvement.
Also, whats the advantage to your new kernel if openvz support isnt available in it? Why not just use the newest debian vanilla kernel?
Lastly, thanks for new ceph integration and improvements. Really looking forward to testing that out. What version of ceph is currently included/supported and will the upcoming Firefly release be supported? Its a huge improvement.
Last edited:
So were moving from Java (which is a pain) that runs on most OS'es, to Spice, which only runs on 2? Should have gone with novnc that runs on everything and doesnt require some third party client.
Java works great on Windows, Linux and OSX, also Android. Spice works on Windows and Linux (including Android) which is also more than 90 % of used client OS.
In 3.2, you have the choice. use Java or Spice.
3.10 is the future default kernel for Proxmox VE. if you want test this one we provide the package. OpenVZ support will follow.
ceph servers use latest main version (currently Emperor) and as soon as Firefly is available, it will use Firefly.
So were moving from Java (which is a pain) that runs on most OS'es, to Spice, which only runs on 2? Should have gone with novnc that runs on everything and doesnt require some third party client.
Also, whats the advantage to your new kernel if openvz support isnt available in it? Why not just use the newest debian vanilla kernel?
Lastly, thanks for new ceph integration and improvements. Really looking forward to testing that out. What version of ceph is currently included/supported and will the upcoming Firefly release be supported? Its a huge improvement.
come one people, relax, and look closely at some key words in this post: test, beta, for now. It isn't so difficult. It means: we are still working on it, we just released this to allow testing by users...
And remember (or read docs) that once (1.x days) pve had multiple kernels, some (usually newer) with only kvm, others (older) with both kvm and openvz, and you could choose at system startup.
There's an amomunt of choices, available. PVE is production and thus stability-oriented, not for bleeding adge and thus unstability. But it's packed with tons of useful features, and a good ui, too.
If you look for always bleeding edge, pve is probably not for you, but the good news is that there are many different and also free solutions out there for you!
:-D
Cheers,
Marco
My questions/statements have zero to do with it being beta or not. It has to do with decisions and directions the product is going and just general questions. The op mentions what is new features and versions and I am simply providing feedback on those.
1) Yes, in 3.2, we have a choice of java or spice (both poor options for complete cross system compatibility), but as mentioned, spice is going to eventually replace java. Java has had a very poor security history the past few years and its blocked on many networks from being installed. So while you might think it works great on all of those operating systems, thats only true if its even installed in the first place. It also doesn't work with every browser (like Chrome that has a large market share). NoVNC has pretty much zero requirements besides a modern browser and works with even more devices than both. Any solution that requires a dedicated client or third party software installed just to access a simple console for troubleshooting or installs is a bad choice. Just my opinion of course, but the opinion is also shared by projects and products much larger than this one.
2) No biggie on the kernel. I probably didnt need to bring it up. I just dont like custom kernels as they mean I cant use ksplice and security releases are delayed. So i was more stating that if openvz support isnt in that kernel at the time, why even have it when the vanilla kernel could be used instead.
3) Thats great news about the ceph versioning. Glad to hear it.
I am sorry but novnc is not such a great winner in our tests. we tested novnc serveral times and it always fails for our needs. instead, spice have great features like copy/paste support, resizing and you can even use local USB devices. Almost all KVM based solutions focus on spice.
RHEL6 is currently the ONLY kernel with openVZ. AFAIK, in future RHEL7 will be only newer kernel with OpenVZ. so as long as you want OpenVZ, there is just no other choice here - seems you missed that part.
I am not sure about the local usb, but novnc definitely supports copy and paste and resizing.
I didnt miss that part at all. I have zero interest in openvz as I only use kvm. You had mentioned that the kernel you were providing didnt have openvz support at that time, so my point was then, why have it at all? Thats all I was trying to say on the subject.
I completely understand. What kind of customizations does it have over the vanilla version of that same number?
There is no short answer for this and a bit outside of the topic of this thread. Search the forum about Proxmox VE kernels and if something is unclear, please open a new thread.
also check http://pve.proxmox.com/wiki/Proxmox_VE_Kernel and the history of this wiki page.
@MACscr
something like this
http://www.spice-space.org/page/Html5
could be one possible solution but I think not on the immediate roadmap. and is a "prototype", as said on the page...
Marco
something like this
http://www.spice-space.org/page/Html5
could be one possible solution but I think not on the immediate roadmap. and is a "prototype", as said on the page...
Marco
According to the OpenVZ Survey, only 39% use KVM only... I really hope that Proxmox will decide to *NOT* remove OPENVZ component ... would be the end!
I'm always stunned by the amount of people who can't understand the statement "for now"...
Marco
I'm always stunned by the amount of people who can't understand the statement "for now"...
Marco
Here in Italy when somebody speaks about "for now", in reality means "forever"... isn't it Marco? Also, it is not the first time that Proxmox staff speaks about to remove OpenVZ support (this was the reason for the survey that I was speaking about)
Last edited:
I also prefer OpenVZ, because about 98% of my vms are just Linux machines. OpenVZ is easier to manage, saves memory and CPU and is faster then full-virtualized machines (KVM), so I don't think that Proxmox will drop OpenVZ support. But that's not the topic here.
The reason why OpenVZ isn't available with the Proxmox Linux 3.10 test-kernel is, because OpenVZ isn't available for Linux 3.10 yet. The OpenVZ team is already working on a version for 3.10, but may take at least some more months.
The reason why OpenVZ isn't available with the Proxmox Linux 3.10 test-kernel is, because OpenVZ isn't available for Linux 3.10 yet. The OpenVZ team is already working on a version for 3.10, but may take at least some more months.
since I've read why it is "for now", I can't imagine how they could think to remove openvz: it's clearly matter of rh kernel & openvz integration, not ready at the moment.
I don't remember any statement like "remove OpenVZ support": I remember use lxc instead of openvz (even dockers was suggested by someone) but I've never read anything like "we're going to remove containers and keep only kvm".
It's one of the strongest point of pve, btw.
marco