I'm using OpenVZ because of the ability to run large numbers of virtual containers. I doubt I'll get the same performance if I was to convert them to KVM instead.
OpenVZ Ploop support
- Thread starter zzhjkrqlne
- Start date
I'm using OpenVZ because of the ability to run large numbers of virtual containers. I doubt I'll get the same performance if I was to convert them to KVM instead.
Hm, are you really calling openvz "limited technology"? Then i'd wonder why it is supported by proxmox at all...
i really like openvz for having large numbers of containers, with easy little "over provisioning". Using "ploop" imo would have quite some advantages:
- snapshots
- snapshots!
- dealing with a single file instead of thousands sometimes could be more practical
jleg
ploop is limited. and OpenVZ is limited to RHEL kernel.
i really like openvz for having large numbers of containers, with easy little "over provisioning". Using "ploop" imo would have quite some advantages:
- snapshots
- snapshots!
- dealing with a single file instead of thousands sometimes could be more practical
jleg
the official openvz docu still tells that ploop is not production ready.
http://openvz.org/Ploop
ah, ok, i agree - but why comparing with KVM here anyway? In comparison with current *OpenVZ* support i'd say ploop is "less limited than standard container fs". At least as a concept, it yet has to prove stability, imo...
Because I always though using a single file is a KVM limitation - now it turned into an openvz feature.
Hi Dietmar, there are no Problems with the current simfs. But some would need the same features that we have if we use KVM. Mainly the possibillity for live migration and high availibility! Thats the main reasons to have a filesystem like ploop for OpenVZ. And Ploop will bring the possibility for other potential image formats like Qcow2, etc. Best Regards, Udo
well, you didn't share this thinking before, so it was a bit difficult to understand...
to be honest, i never had the idea to doubt the KVM single-file-approach, since this imo always used to be "well known cemented standard" in VM industries... (probably introduced to the wider public by VMware).
But is there any VM system based on single files for the guest?
And they really want to implement something like qcow2 in kernel space?
- - - Updated - - -
There is some code for KVM (http://www.linux-kvm.org/page/VirtFS)
Actually ploop was made to circumvent the current bottleneck for large openvz installations - the filesystem journal and inodes.
this actually does look interesting. Now I cant help but wonder whether itll be possible to use this for the whole system disk at some point, which could be tricky, especially since probably 99% of KVM VMs host windows
Last edited:
So Dietmar, is it likely that we'll see Proxmox officially start supporting Ploop any time soon? You've previously mentioned a DIY approach, but I'd rather see Proxmox supporting it officially so that I can start using it without having to worry whether it'll be broken in future releases of Proxmox.
The sorry part is that ZFS isn't GPL compatible ;(
When you look at the Solaris Zones on ZFS implementations, you'll see how these problems that ploop/simfs tries solve are close to a non-issue:
- snapshots per filesystem
- size/quota can also be changed 'on-the-fly' inside the pool
- I have yet to hear/see an inode/journal contention on ZFS with it's C.O.W. setup (with L2ARC on SSD/etc. you have other speedups too)
Any news regarding ploop support in Proxmox?
According to Kir's git, it has already reached stable status 4 months ago in version 1.7. Now it is at 1.9, and looks pretty well maintained.
http://git.openvz.org/?p=ploop;a=summary
According to Kir's git, it has already reached stable status 4 months ago in version 1.7. Now it is at 1.9, and looks pretty well maintained.
http://git.openvz.org/?p=ploop;a=summary
The key question for us is how fast they provide patches for RHEL7 kernel. The plan is to include it when we switch to RHEL7 kernel.
That could be a year from now... even the first beta of RHEL7 isn't expected to land until well into 2014, not to mention the lead time of the OpenVZ team.
Any special reason to not include ploop in the current kernel? Earlier you guys said "when it reaches stable"...
I have noticed now, that the ploop snapshots feature would be a very welcome addition to our current backup strategy.
Hope it gets introduced soon. (sooner then RHEL7)
Hope it gets introduced soon. (sooner then RHEL7)
I'm interested in ploop because I run my VMs on an xfs file system. It's well-known that vzquota doesn't support xfs (https://bugzilla.openvz.org/show_bug.cgi?id=128) and according to that bug, vzquota is now deprecated in favor of ploop. It seems the OpenVZ team would like everyone to migrate to the ploop format anyway, so it might soon be inevitable.
It seems easy to just enable on a ProxMox system (add VE_LAYOUT=ploop in /etc/vz/vz.conf) but I don't want to do that if the rest of the ProxMox system (GUI, etc) isn't prepared to handle it. (As for the kernel, 2.6.32-26-pve seems to already have the ploop and pfmt_ploop1 modules loaded.)
And what's this about the RHEL kernel? I'm running a Debian system.
It seems easy to just enable on a ProxMox system (add VE_LAYOUT=ploop in /etc/vz/vz.conf) but I don't want to do that if the rest of the ProxMox system (GUI, etc) isn't prepared to handle it. (As for the kernel, 2.6.32-26-pve seems to already have the ploop and pfmt_ploop1 modules loaded.)
And what's this about the RHEL kernel? I'm running a Debian system.