New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
No. I will not buy openvz.
It has been almost 1 year since Debian 12 release. But Openvz don't have it.
No, life is too short to deal with OpenVZ (it's too much of a black box where it's never completely clear what you will actually get when buying it).
Countdown to OpenVZ 7 End of Maintenance: 1 week.
Countdown to OpenVZ 7 End of Life: 13 months.
More information: Virtuozzo Product Lifecycle Policy.
There are many LAZY providers in the world.
For KVM, I can install manually IT via ISO or netboot.
I don't want ask "Do you have ~~~ template ?"
LXC is a much better option.
too limited for most my server need. got to add some userspace program to use basic linux use. not worth the effort to make it work when now kvm offers were much cheaper than few years ago. this is my experience only. other people usage & experience may vary.
https://bitbucket.org/openvz/debian-12.0-x86_64-ez/src/dist-vz7-u20/
--
To the topic at hand:
OpenVZ absolutely does have a market.
Most people really don't care about the virtualization technology - they just want something where they can host their website, store their backups, run their VPN, etc - and OpenVZ allows all of those things.
I use proxmox, which uses lxc
Yeah, if container virtualization then LXC. I'm also not much of a LXC (or really any type of container) fan (neither from a user nor administrator perspective) and probably wouldn't buy just based on that but at least it's a native and relatively well documented system that doesn't depend on the snail speed update cycle of some company.
We use LXC internally within the KVM, rather than running KVM-in-KVM nested virtualization.
This way we don't have to partition resources among these LXC containers.
Every container can use up to the maximum cores, RAM, and diks as needed.
Depending on your setup/goal that might make perfect sense. I wouldn't want to nest KVM either but then i'm also not big into containerization so i'm not sure i've yet run into this scenario.
I'd probably use containers more (internally - when i order a VPS there would need to be some good reason for me to choose anything but full hardware virtualization) if setting up non-root containers without additional frameworks would be a bit less configuration intensive though. Initially i was quite excited as it seemed like a chroot on steroids which would work without root rights but setting up all those ids, mappings and whatnot kind of spoiled it for me. Well, i guess there's always the option to write a couple clever scripts. Maybe some day, who knows?
Playing with LXC i learned about
mmdebstrapthough. Highly recommended for anyone trying to build minimal Debian derived systems/images. It's basicallydebootstrapbut way less clunky.What's better to ride a city public bus or in a car with a personal driver? The situation is about the same when both are moving, but the question is with what additional possibilities and level of comfort.
Depends entirely on who's driving.
KVM doesn't inject some magic potion into virtualization to make it superior to other VT technologies - there's plenty of KVM hosts that offer sub-par experience (stability, performance, the control panel, etc).
OpenVZ is for noobs @EthernetServers
Usually those who still provide this obsolete virtualization only to save on resources defend it. It's like advertising HDD as a cheaper alternative to SSD.
its the end for openvz.
As far as we are concerned we already migrated all our OVZ VM's to KVM few months ago, we still have some OVZ clients left out who don't want to migrate to KVM yet, but may be in a coupe of months we even will migrate them
As far @EthernetServers is concerned, George knows what he is doing and there is still huge market for OVZ as we regularly get requests OVZ
Definitely.
Especially for true low-end VPSes, which have 128, 256, or 384 MB RAM.
KVM eats too much extra memory unlike OpenVZ's shared kernel.
This.
Because people are noobs
Why would you choose OpenVZ over LXC here? Genuine question.
Obviously. It's not your kernel then though and you will be limited to whatever that kernel thinks is best and non-Linux systems are out of scope too. Also the walls between you, the host and the other guests are paper thin. It's not like you could actually secure a KVM from host access but you can make it at least comfortably inconvenient.
I also wonder if you can you dd diskimages (aka poor man's snapshots) in OpenVZ? Again genuine question. I don't think that i've ever tried this when i was playing with OpenVZ somewhere in the last century
By the way, what's the problem with 128MB KVMs? I've used an old Laptop with 64MB RAM as a router for years and years with zero problems. Sure Ubuntu would likely choke and probably even (default) Debian these days but that really isn't the fault of the RAM or KVM but really those systems having become so incredibly bloated. Nothing a little DIY can't fix.
I guess, i agree. To people who wouldn't know the difference anyways, which is - let's face it - probably the majority of users, it's obviously all the same. Once the latest Ubuntu doesn't install anymore there might some learning happening though
I have no experience working with LXC, so I cannot comment first hand, but I was having a chat with Phill of VirtFusion recently and he said this:
Even though this thread is about OpenVZ, I wouldn't mind hearing more thoughts about LXC.
Interesting. I'm (by far) not deep enough into the subject to comment on that but i'd love to hear more on it too as i have a hard time imagining what kind of gotchas these could be. To me it seems that if it's good enough for local isolation it should be good enough for untrusted users too but i'm probably missing something. There's a good couple providers actually offering it though, so it should be possible, i guess.
Edit: Maybe @Neoon can chime in.
I’m balls deep and can confirm that OpenVZ still sucks
hello,
it s possible you like ovz if my im give you container that it s FREE and have DARK MAGIC?
hocus pocus only kvm in my focus
Regards
Same crap but in a new rebranded package. That's what they do when a product stops selling.
There is also
cdebootstrapwhich is basically debootstrap written in C, therefore it's far more light-weight thandebootstrap(3k lines bash + a script for each distribution) ormmdebstrap(8k lines Perl, depends on apt). Butmmdebstrapseems to be the fastest out of the three,cdebootstrapis close second anddebootstraparound half the speed ofcdebootstrap(at least in my tests, surely influenced by disk/network/CPU speeds).Until now I only used
debootstrap, but now I'll likely usecdebootstrapinstead as it's faster. I won't usemmdebstrapthough because it's only slightly faster thancdebootstrapand I prefer compiled programs.And containers generally are (in my opinion) great and very simple to use. Essentially chroot+unshare+cgroups does all the magic, and a program to simply start a container are only a few dozen lines of C. And containers can be very useful - I use them (nearly) daily, I run YABS inside of a container to prevent it from breaking/deleting something, and for consistent build environments they are also very useful: on my laptop (with an i7 from 2017 and 100 Mbit/s download) it only takes 50 seconds to
cdebootstrap)Regarding OpenVZ, I'd say that LXC has the advantage that it works with a standard kernel and doesn't need patches. Personally I would prefer KVM because there you simply have more control and some things simply aren't possible with containers.
Charging more doesn't make much sense as the provider can oversell more as there is less overhead and the container doesn't use memory for file cache (or rather the memory can be freed easily).
For me the reason i like
mmdebstrapis actually the way it works.debootstrapand variants need 2 steps with the second needing to run inside the target system, which is not that bad as long as the target system is the same as host's or it's at least somewhat similar but beyond that it gets quite unfun. Also i like to have my scripts run as non-root and messing around withfakeroot,fakechrootand such is quite clunky and error prone, so finishing the system often means Qemu to the rescue, which is ok-ish but also seriously clunky and not exactly fast.Been a while since i've played around with it and i agree by default it seems pretty easy but once i tried moving to privileged containers (i might be messing up the terminology here - basically containers that fully represent an autonomous system) started by non-root users (which is really what i'm after - using root outside of administrating the box i'm logged in to is a big no-no to me) it really wasn't all that convenient anymore. Also it seemed the user creating the containers didn't have a lot of control over the files that were created by them so simply deleting the filesystem after use meant jumping through hoops. I really tried to like it (actually i was quite excited as i had thought to finally have a clean alternative for chroot that didn't need root) but at some point i just had to accept that it simply didn't work out as well as i had hoped.
Well, chroot would pretty much do the same thing though, wouldn't it?
Yeah, in hosting environments KVM is probably usually the best option even if it costs a little more due to additional overhead. Containers seem to rather shine when used for isolation. There's a lot of people, which wouldn't notice the difference though.
Didn't knew that, then mmdebstrap is not only the fastest but also has other advantages.
Yeah, with a non-rot user it is much more difficult, starting at chroot.
Nginx pretty much yes, but not YABS (aka untrusted programs/code) because it could reboot or mknod the filesystem device (I think) and manipulate/delete the data or load a kernel module.