# OpenVZ



## HN-Matt (Jul 17, 2015)

So there's the sport of criticizing or shitting on OpenVZ for all the usual reasons. Blah blah merely a container with the door left... _open_, oh me oh my, vzctl enter, etc. I'm curious about the extent to which contempt for OVZ contradicts claims toward a preference for open source principles and theory/practice. It seems a strange, ambivalent, confused perspective in certain respects. The desire for open code in the service of closed systems. Probably an obvious question, but I'm curious about it in the context of rhetoric used against OpenVZ from the condescending view of the die hard KVM mech-warrior connoisseurs. If you want closed, ultra-secure, impenetrable systems, why not take the thought all the way and go full proprietary?


----------



## wlanboy (Jul 18, 2015)

It might be too short to boil this down to just KVM vs OpenVZ.

OpenVZ like Xen does have the disadvantage of patches.

LXC and KVM are part of the kernel. And even if OpenVZ is closed ... it is all about patching a RHEL kernel. And a single company able to patch it.

I am not talking about the quality or actuality of the RHEL kernel but e.g. Docker shows what you are able to build on top of LXC. 

Nvidia does build kernel modules. Yep they are closed source but you are not bound to one version of one kernel to use them.

LXC and KVM are running on CentOS, Debian, Ubuntu, Suse, Slack, .... and OpenVZ?

Even the OpenVZ team admits that they took the worst architecture to build OpenVZ and that they try to rebuild it as part of the kernel.


----------



## HN-Matt (Jul 18, 2015)

wlanboy said:


> It might be too short to boil this down to just KVM vs OpenVZ.


Yeah, guess I didn't mean strictly from the perspective of KVM. There's certainly other virtualization technologies. KVM seems to be the more popular vista used to trash OpenVZ, though.


----------



## joepie91 (Jul 18, 2015)

HN-Matt said:


> If you want closed, ultra-secure, impenetrable systems, why not take the thought all the way and go full proprietary?


Because there's two different things at play here - "security through obscurity" vs "security by design". A "proprietary" system has to do with the former, whereas picking KVM (to some degree) has to do with the latter.


----------



## DomainBop (Jul 18, 2015)

HN-Matt said:


> There's certainly other virtualization technologies.


umm yeah, that is true...VMware and Hyper-V have about 75% of the virtualization market (based on Gartner's annual survey in 2014).  KVM is growing strongly mainly due to the growth of OpenStack but it still only accounts for a relatively small percentage of the server virtualization market (and Xen's share is even smaller)



> So there's the sport of criticizing or shitting on OpenVZ for all the usual reasons. Blah blah merely a container


Those "usual reasons" (using own kernel, increased isolation from noisy neighbors, etc, etc) are very valid reasons why many of us choose a virtualization solution over a containerization solution.  Everyone has different needs so OpenVZ is a perfectly acceptable solution for many people.



> oh me oh my, vzctl enter,


The problem isn't "vzctl enter", it is the fact that some providers (_who seem to gravitate towards offering openvz_) give system/administrative access to the poorly vetted contractors (or outsourced help) they found on Skype, a hosting forum, IRC, recess/detention hall, or give system access to minors. Giving system access to poorly vetted workers is a major security problem whether the host is using OpenVZ or KVM or Xen .  _If I used OpenVZ,_ I would have no problem trusting my company/employee/customer data to a server with an OpenVZ provider if they could answer this set of questions to my satisfaction (or if the provider themselves is ISO27001 certified,).  

TL;DR you need to be able to trust your provider, and you need to do your research before you upload your important data to their servers.



> If you want closed, ultra-secure, impenetrable systems, why not take the thought all the way and go full proprietary?


Windows...cough is a proprietary system and I don't think anyone has ever accused it of being ultra-secure or impenetrable or even more secure than its open source OS competitors (and in the hosting world those masters of obfuscated code SolusVM and WHMCS are also proprietary software).  The virtualization technology used by a provider is the least of my worries when it comes to security (see my previous comment on poorly vetted workers).


----------



## HN-Matt (Jul 18, 2015)

DomainBop said:


> The problem isn't "vzctl enter", it is the fact that some providers (_who seem to gravitate towards offering openvz_) give system/administrative access to the poorly vetted contractors (or outsourced help) they found on Skype, a hosting forum, IRC, recess/detention hall, or give system access to minors. Giving system access to poorly vetted workers is a major security problem whether the host is using OpenVZ or KVM or Xen .


Right, and yet you'll see 'vzctl enter' being painted as the boogeyman from time to time when the problem exists at a different level.

Likewise to some extent with the 'security through obscurity' and 'security by design' contrast, where a shinning example of the latter becomes immediately meaningless in the wrong hands or whatever. That's what I'm getting at when I say theory/practice. I think a lot of the debate is obfuscated by focusing too hard on technical aspects of the software, as if it were a cure-all by merely being designed in a certain way.

e.g. having a coughing fit re: 'Windows' from the helm of a terribly administered and completely exploited open source oasis.



DomainBop said:


> The virtualization technology used by a provider is the least of my worries when it comes to security...


Yes, that's what I was leaning toward. So much noise in the battle re: virtualization technology and it amounts to nothing in certain admin contexts. It sometimes feels as if the software is the rhetorical equivalent of a diversionary trust gaining graphic. Or propped up as a way to avoid thinking about certain central/crucial problems that aren't software related.


----------



## HN-Matt (Jul 19, 2015)

I haven't read this in years: If It Doesn't Exist on the Internet, It Doesn't Exist.

I didn't read it today either and don't remember its contents, but the title alone is interesting when thinking about the phrase 'security through obscurity'. Obviously we can say that software 'exists' on the internet while those who control it do not. It seems to me that if not more then at least often-less-considered bursts of 'obscurity' comprise the gaps between virtualization technology and administrative context. Of course the absence of a 'vzctl enter' equivalent is also a form of obscurity.


----------



## HN-Matt (Jul 19, 2015)

DomainBop said:


> Windows...cough is a proprietary system and I don't think anyone has ever accused it of being ultra-secure or impenetrable or even more secure than its open source OS competitors (and in the hosting world those masters of obfuscated code SolusVM and WHMCS are also proprietary software).


Sure, and yet there can be endless crying and hand-waving about 'Windows' as an excuse to move to XYZ only to end up in a new administrative context that is ten times more exploitative and in less obvious or less defamiliarized ways.


----------



## HN-Matt (Jul 22, 2015)

A false sense of security: http://www.lowendtalk.com/discussion/58501/encrypt-xen-virtual-machine#Comment_1177591


----------



## HN-Matt (Jul 22, 2015)

KVM vs. OVZ battle on LET: http://www.lowendtalk.com/discussion/58690/why-kvm-whips-openvz-s-ass-for-webhosting


----------



## Tyler (Jul 22, 2015)

Can't we just agree that they both have their places in the marketplace and each has its advantages and disadvantages? What may be an advantage for one may be a disadvantage for another.

I personally find it reductive to try to find an overall winner in a battle similar to what's linked on LET.


----------



## HN-Matt (Jul 23, 2015)

I wasn't trying to find a winner. I mostly wanted to demystify the rhetoric used to attribute a false sense of security to certain virtualization technologies that are known for 'superior isolation' (don't worry, I won't bother trying to psychoanalyze KVM). As to performance and preference, I don't really care. To each their own.



Tyler said:


> I personally find it reductive to try to find an overall winner in a battle similar to what's linked on LET.



I linked to those threads because of timing, not because of any particularly interesting content.


----------



## Geek (Jul 23, 2015)

I'm finally intrigued by an OVZ vs KVM vs VMW vs LXC vs a cardboard box vs a kitty.....

Wait, where was I?  

Think I'll sit back and watch this time.  I need a breather!


----------



## HN-Matt (Jul 23, 2015)

Geek said:


> I'm finally intrigued by an OVZ vs KVM vs VMW vs LXC vs a cardboard box vs a kitty.....
> 
> Wait, where was I?
> 
> Think I'll sit back and watch this time.  I need a breather!



Oh, no, Please go on!

All that watching..... why stop now?


----------



## Geek (Jul 24, 2015)

I'm just not up for talking shop atm. I've had a two-day headache.  
 

....what were those questions you mentioned ealier?  I'll take a stab at em later.


----------



## TheLinuxBug (Jul 25, 2015)

My issue with openvz stems mostly from the administrative perspective - it is so easy for a newbie sysadmn who thinks they know what they are doing to go in and mess with things on the file system level - don't confuse this with me being concerned with them seeing my files, more so one wrongly done rm -rf can end with a whole server of useless containers - look at what happened to Hostress as an example. At least on kvm/xen they (in most cases) would have to purposely remove the lvm volume  to do the same damage. There some other things I would mention but this editor lags the crap out of my moto x for no reason and its become inconvenient to try and continue to respond.


----------



## HN-Matt (Jul 25, 2015)

Yeah, that's a legitimate concern, newbies and accidents, but again, not really what I was getting at.


----------

