Slashdot Mirror
Virtual Containerization
AlexGr alerts us to a piece by Jeff Gould up on Interop News. Quoting: "It's becoming increasingly clear that the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on. It's all about 'containerization,' to employ a really ugly but useful word. Until fairly recently this was anything but the consensus view. On the contrary, the idea that virtualization is mostly about consolidation has been conventional wisdom ever since IDC started touting VMware's roaring success as one of the reasons behind last year's slowdown in server hardware sales."
The great thing about virtual machines is that you basically can do whatever you want with them. Things you'd normally never do to your computer.
It's only lacking a feature of throwing the virtual computer out of the window.
Sure, containerization might sound like a good idea... but if you find the word 'containerization' ugly NOW, wait until you see what furry abominations grow in the containers you forget about at the back of the work server for 2 months. >_>
The word is contain, people, not containerization.
If you're "containerizing" every aspect of your system, doesn't this have big performance problems? CPU cache, message passing, memory management, DMA, IRQs, whatever?
What was wrong with traditional privilege isolation in Linux systems (running processes as different users, chroot, etc)?
As a software developer, being able to take snapshots, clone, pause, rewind (via snapshots) and backup makes VM'ing worth the cost in CPU/performance.
It's proved so useful that I'm sincerely considering doing the same for my actual WWW server so that if at any given time things go -bad- on the device I can just either roll back or transparently transfer to another machine, the latter, due to the (mostly) hardware agnostic nature of the VM setup makes disaster recovery just that much simpler (sure, you still have to setup the host but at least it's a simpler process than redoing every tiny little trinket again).
I'm sorry, thats an attempt to jump on the virtualization bandwagon. Use that word these days, people throw money at you.
Application isolation is not virtualization, its nothing more than shimming the application with band aid APIs that fix deficiencies in the original APIs. Calling it virtualization is a marketing and VC-focused strategy, it has nothing to do with the technology.
I've used virtualization for both containerisation and also to consolidate boxes too...
At my previous company, we invested in two almighty servers with absolutely stacks of RAM in a failover cluster. They ran 4-5 other servers for critical tasks...each virtual machine was stored on a shared RAID5 array. If anything critical happened to the real server, the virtual servers would be switched to the next real server and everything was back up again in seconds. The system was fully automated too, and frankly, it saved having to buy several not-so-meaty boxes while not losing much redundancy and giving very quick scalability (want one more virtual server? 5 minute job. want more performance? Upgrade redundant box and switch over virtual machines).
The system worked a treat, and frankly, the size & power of the bigger, more important fewer servers gave me a constant hard-on.
throw new NoSignatureException();
I've only had an X86 box at home since the 80s and only this year putting XP Pro on a qemu cylinder with a Samba share _finally_ got me to rigidly separate the OS that I can zip tar and burn to DVDs for backup and the data on the Samba share that I can backup regularly. Now if I can benefit from the example and get more professional about the greater linux machines in the home.
In case your interested, the article is really a review of rPath, a virtual appliance builder based on a custom tailored gnu/linux...
I read somewhere (possibly on the PHP bug system) that they were considering scrapping most fo the security features we've all grown the .. well, hate really, and replace them all with a virtualisation system. I did think at the time that the virtualisation system they'd implement to keep PHP-based vhosts separate and secure would be to run apache in many virtual OSes.
I suppose jailing applications is a well-known way of securing them, this really just improves on that, but with much more overhead. I wonder if anyone is thinking about providing "lightweight" virtualisation for applications instead of the whole OS?
... that develops applications, mostly in C, I also find it extremely useful, especially when installing software. Some installers change the state of the system, some problems only occur first time round. There is nothing else like the ability to take your blank windows VM, copy it, install stuff, screw around with it in every possible way and then when you're done just delete the thing. They also allow you to install stuff you just don't want on your native box, but need to develop against.
And you still have that blank windows install to clone again when you need it.
VMs are a fantastic dev tool.
It's becoming increasingly clear that the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on. It's all about 'containerization,'
Don't trust "it's all about" or "it turns out that to the contrary" or "set to fully replace" statements, especially when there's lack of evidence of what is claimed.
Hosting services use virtualization to offer 10-20 virtual server per one physical machine, I and many people I know use virtual machines to test many configurations we can't afford to have separate physical machines for.
So even though it's also about "containerization" (is "isolation" a bad word all of a sudden?), it's not ALL about it.
Why are we reading stuff from a site like that? If they're not already shilling, they will be as soon as MS has it's hypervisor ready.
If I wanted containers, I'd be using Solaris, Jails or chroot.
Solaris has Zones for that exact purpose. Lguest, I believe, offers something similar for Linux.
With virtualization like linux vserver, xen, vmware etc. there are two main reasons to why people are using it.
1) Consolidation
2) "Containerization" or whatever their calling it today.
The company that I work for are using multiple virtual servers to be able to keep applications separate and be able to migrate them from machine to machine easier which is a common use for vmware (e.g. the appliance trend). So you're trading performance and memory usage for security and robustness/redundancy.
Across maybe 100-200 servers, the number of vservers we have is astonishing (probably around 1200 to 1500, which is a bit of a nightmare to maintain) which are hosting customer applications, when an application starts to use more resources the vserver is moved over to a machine with less servers on it, and gradually to it's own server, which in the long run saves money & downtime.
The other major industry using them is the hosting industry, allowing customers a greater amount of personalization rather than the one-size-fits-all cpanel hosting companies. This is the real industry where consolodation has increased, biting into the hardware markets possible sales because thousands of customers are now leasing shared resources, instead of leasing actual hardware.
Either way, the number of new machines (virtual) machines and ip addresses, all managed by different people is becoming a management nightmare. Now everybody can afford a virtual dedicated server on the internet regardless of their technical skills which often ends up as a bad buy (lack of memory and resource constraints compared to shared hosting on a well maintained server).
What do you run inside a virtual machine - an OS!!
What do you run the virtual machine on - an OS!!
So, any application now has to withstand two OSes, not just one. Isolation can be an important part of virtualization, but it's about isolating applications from each other, not from the OS.
I've been using an XP SP2 vm for downloading Cory Doctorow nudes. Wife needs to use the pc? She just uses the host OS, and my precious guest OS goes untouched,
That can be a chilling thought to companies like Intel, Microsoft or Oracle. Also, the carefully woven concoluted DRM and TCPA architectures that consume gazillions of instructions and slow down performance to a crawl... will simply be impossible if the Virtualisation layer simply ignores these functions in the hardware. Which is why I felt it very strange for the Linux Kernel team to get involved in porting these VMs in order to allow Vista to run as a guest OS. It shouldn't have been a priority item for the kernel team at all, IMO.
If you keep throwing chairs, one day you'll break windows....
This is kind of obvious, I used to use more machines for security reasons, now I use less machines but they are more powerful. When you do server consolidation, it implies that applications used to run on different hardware for security and stability reason will now be running on the same hardware within different VMs. So how can they say "protect applications from the vagaries of the operating environments" is opposed to "consolidating hardware box".
"Consolidating hardware boxes" implies "protect applications from the vagaries of the operating environments" you just do that with less machines.
I use virtualization because it leaves me with less physical servers to manage, "protect applications from the vagaries of the operating environments" was already done before virtualization. So, virtualization doesn't help me "protect applications from the vagaries of the operating environments", it helps me because I have less servers to manage.
Everything I write is lies, read between the lines.
What's wrong with 'compartmentalized', 'compartmentalization', and 'compartmental'? I think most people understand what they mean. And they sound less ghey too.
I use vmware servers for software that is node locked.. Node locked software is usually done by a machines MAC address, I find that using VMs reduces downtime in the event of either host or client failing. In the case of the host if we can recover the VM we just copy it to another host and run it. In the case of the client dying the great thing is I just create a new VM and change its mac address to match the dead one then reinstall my licence files, saving me from having to reregister all of the licences to the "new" machine.. Hardware consoladation also plays a large part of my use of VMs, but the main reason is recoverability so much so that all my DCs are on VMs so if their host dies (hardware other than HDD) then i can either pull the disks and put them in another machine, or if my replication has succeeded more recently then I just start my backup copy of the DC and let it update from the domain. Total downtime is about 15min tops.
Is there actually a metric of why companies are turning to virtualization somewhere? We are doing it for stability of applications to a very small degree, but also for development ease, backup ease and also for a big part to consolidate and use hardware more efficiently. What about you, why are you considering/using/investigating virtualization?
B) Eliminate all the stupid users. This is frowned upon by society.
the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on
Most important means different things to different people.
In the real world, to run a reasonably reliable application requires a modern rackmount server with remote out-of-band management, redundant power supplies and RAID. The most common failure modes for computers are hard disk and power supply failures, and this protects you from both. Remote management lets you control & reboot the machine from offsite.
These kinds of servers are available off the shelf from any major vendor (Dell, HP, IBM, etc) and will run you $2000 or so. Given the speed of computers today, that server will run most apps really, really fast. In fact, many apps will rarely go above 10% utilization (you do monitor your servers with SNMP, right?).
So, to get a reliable server with next-day onsite parts replacement, you had to buy far more server than you need. Many (most?) data centers are full of servers like this.
For one software project I'm working on, the vendor recommends 5 servers: one for oracle, two for crystal reports, and two application servers. The vendor recommends hardware costing $40,000. This is for a custom software app that will have 5 users. Yes, 5 users, and it's not a complex app that demands a lot of performance. Having talked to other customers, utilization rarely goes above 3%. Quite a waste, even though the total project cost is $200,000.
Hardware consolidation with VMware can lead to very big savings in hardware, colocation, power, cooling, and admin costs.
And if you get the Vmotion software from VMware, you can move a running virtual machince from one server to another, while it is running, without skipping a beat. That is very, very useful. Need to take your real server down for maintenance? Move the virtual machines to another server. Need to do your end-of-month reconciliation? Move it from the slow backup server to the big fast number cruncher.
I run a whole bunch of virtual servers and that's exactly what I'm doing.
It's fantastically handy to be able to install and configure a service in the knowledge that no matter how screwed up the application (or, for that matter, how badly I screw it up), it's much harder for that application to mess up other services on the same host - or, for that matter, for existing services to mess up the application I've just set up.
Add to that - anyone who says "Unix never needs to be rebooted" has never dealt with the "quality" of code you often see today. The OS is fine, it's just that the application is quite capable of rendering the host so thoroughly wedged that it's not possible to get any app to respond, it's not possible to SSH in, it's not even possible to get a terminal on the console. But yeah, the OS itself is still running fine apparently, so there's no need to reboot it.
This way I can reboot virtual servers which run one or two services rather than physical servers which run a dozen or more services.
Granted, I could always run Solaris or AIX rather than Linux, but then I'll be replacing a set of known irritations with a new set of mostly unknown irritations, all with the added benefit that so much Unix software never actually gets tested on anything other than Linux these days that I could well find myself with just as many issues.
Isn't this de facto evidence that the sandboxing, which was supposed to be a key component of both Java and .Net's security models, has either failed to deliver on their promises, or simply isn't adequately well engineered to provide protection against rogue applications?
As has been said before, we need a way to grant applications permissions to use resources. We have that, to some degree, with firewalls and apps like ZoneAlarm/LittleSnitch which ask you for permission before an application is allowed to "call home", but what about other resources -- for example, being able to access only a particular directory or install a system-level event hook which acts as a keylogger? etc.
Whatever was wrong with the vastly less unpleasant term "compartmentalization," which is already, you know, a word?
We in the mainframe VM world have been doing this for 40 years. I get a kick of you microcomputer idiots constantly reinventing everything... badly.
So in the future we will not release rpm packages and setup files but VM images to our customers? Ok, why not. It could ease deployment of highly customizable enterprise software. So you basically deploy all the OS config with it. Sounds cool. No more telling the sysadmin to open ports, create mount points, set permissions, install init scripts, update this and that library, etc.
Well, yes and no.
As I keep telling people when I work with virtualization, it does not necessarily lead to server consolidation in the logical sense (as in instances of servers), rather it tends to lead to server propogation. This is probably expected; generally I/O will be lower for a virtual machine than for a physical machine, thus requiring the addition of another node for load balancing in certain circumstances. However, this is not always the case.
Virtualization DOES help lead to BOX consolidation; as in it helps reduce the physical server footprint in a datacenter.
Let me give you my viewpoint on this; generally virtualization is leveraged as a tool to consolidate old servers to bigger physical boxes. Generally, these old servers (out of warranty, breaking/dying and so on) have lower I/O requirements anyway so often see a speed boost going to the new hardware... or at the very least performance remains consistent. However, where new applications are being put on virtual platforms, quite often the requirements of the application cause propogation of servers because of the I/O constraints. This is generally a good thing as it does encourage the developers to write "enterprise ready" applications that can be load balanced instead of focusing on stand-alone boxes with loads of I/O or CPU requirements. This is good for people like me as it provides a layer of redundancy and scalability that otherwise wouldn't be there.
However, the inevitable cost of this is management. While you reduce physical footprint, there are more server instances to manage, thus you need a larger staff to manage your server infrastructure... not to mention the specialized staff managing the virtual environment itself. This is not in itself a bad thing, and generally might lead to better management tools, too... but this is something that needs to be considered in any virtualization strategy.
Generally in a Wintel shop, more newer applications get implemented in most companies these days. This is particularly true since most older applications have been or need to be upgraded to support newer operating systems (2003 and the upcoming 2008). This means that the net effect of all I've mentioned is an increase in server instances even while the footprint decreases.
"Containerization" (yuck!) is not new by the way. This is just someone's way of trying to "own" application isolation and sandboxing. People have done that for years, but I definitely see more of it now that throwing up a new virtual machine is seen as a much lower "cost" than throwing up a new physical box. The reality of this is that virtualization is VERY good for companies like Microsoft who sell based on the instances of servers. It doesn't matter if it's VMWare or some other solution; licensing becomes a cash cow rapidly in a virtualized environment.
Where I work we've seen about a 15% net server propogation in the process of migrating systems so far. Generally, low-load stuff like web servers virtualize very well, while I/O intensive stuff like SQL does not. However, a load-balanced cluster pair of virtual machines on different hardware running SQL can outperform SQL running on the same host hardware as a single intstance... this means that architecture changes are required, and more software licenses are needed, but the side effect is a more redundant, reliable and scalable infrastructure... and this is definitely a good thing.
I am a big believer in virtualization; it's somewhat harking back to the mainframe days, but this isn't a bad thing either. The hardware vendors are starting to pump out some truly kick-ass "iron" that can support the massive I/O that VM's need to be truly "enterprise ready". I am happy to say that I've been on the leading edge of this for several years, and I plan to stay on it.
I prefer "encapsulation" myself
Do not mock my vision of impractical footwear
Indeed! I was programming an app which required me to test it on a completely clean windows box, as well as different patch levels (vanilla, SP1, SP2, current) for both Home and Pro versions, which meant that I'd have to reinstall after each test run. With being able to install each from CD, snapshot the clean machine, and then zip a copy of the folder and drop it over to my server in case I killed or corrupted the initial snapshot, I could have a clean machine after each run within a few seconds. Furthermore using VMWare, I could mount an ISO to all the virtual machines as the CD ROM drive, and then I just had to compile and drop the binary into the ISO and it was ready on all 8 iterations of Windows. Lastly, (and the first on topic thing I'll say) due to the nature of the project, I had to infect the Windows virtual machines while they were on my dev box (for lack of another sufficiently powered box at that time), which is great when I'm physically (at the file system level) removed from an infected box! Without VMware, I'd still be writing the app.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Virtualization also allows less important individual OS instances to be made highly available. In some cases there are several tier-2 applications, which we would like to have redundancy for, but cannot afford a second physical box for each. However, we can justify two clustered VM nodes, which will host all of those smaller applications, each on their individual OS, for containerization, and gain the reliability that makes us sleep a little easier at night.
Sure, but if you use a VM for each application, you have easy containerization.
The reason we run Vi3 is so that we can deploy servers on demand. There's no need to prep hardware. You just right-click and deploy. And, yes, the initial impetus was to consolidate from about 20 hardware servers down to two. We now run about 40 virtual servers on 4 octo-core servers. Consolidation is definitely at work here. "Containerization" is a stupid word, as it's entirely possible through non-virtual deployment (100% probable, in fact). Virtualization is about flexibility in stack deployhment, but mostly serves to provide more stacks per core than is possible in similarly priced hardware.
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
The trend that I expect to happen is to start deploying isolated "Black Boxes". For example - instead of installing redhat and deploying our software on top of it - just ship an already configured VM. I know there are license issues to work out - but in the end, just deploying specialized VM's may be the best case.
Within a VM system, one will now find three types of systems running in the virtual machines.
It is these Service Virtual Machines that equate to the topic of the original post. A SVM usually provides one specific function, and while there may be interdependence between SVMs (for example the TCPIP SVM that provides the TCP/IP stack and each of the individual TCP/IP services), they are pretty much isolated from each other. A failure in a single SVM, while disruptive, usually doesn't impact the whole system.
One of the first SVM's was the Remote Spooling Communication Subsystem (or RSCS). This service allowed two VM systems to be linked together via some sort of communication link -- think UUCP.
The power of SVM's is in the synergy between the Hypervisor system, and a light weight platform for implementing services. The light weight platform itself doesn't provide much in terms of services. There is no TCP/IP stack, no "log in" facility (only relying on the base virtual machine login console), and maybe not even any paging memory (letting the base VM system manage a huge address space). Instead a light weight platform will provide a robust file system, memory management, and task/program management. In IBM's z/VM product, CMS is an example of a light weight platform. The Group Control System (GCS) is another example (GCS was initially introduced to provide a platform to support VTAM - which was ported from MVS).
Part of the synergy between between the Hypervisor and the SVMs is that the Hypervisor needs to provide a fast, low overhead intra-virtual machine communication path that is not built upon the TCP/IP stack. In otherwords the communication between two virtual machines should not require that each virtual machine contain it's own TCP/IP stack with it's own IP address. Think more along the lines of using the IPC or PIPE model between the SVMs.
Since the SVM itself is not a full suite of services, maintenance and administration is done via meta-administration, in otherwords you maintain the SVM service from outside the SVM itself. There is no need to "log into" the SVM to make changes. Instead of the SVM providing a sys-log facility, a common sys-log facility is shared among all the SVM's. Instead of each SVM doing paging, simply define the virtual machine size to meet the storage requirements of the application, and let the Hypervisor manage the real storage and paging.
Maybe a good analogy would be taking a Linux kernel and implementing a service via using the init= parameter in the kernel to invoke a simple set up (mounting the disks) and running just the code needed to perform the service. Communication for other services would be provided via hypervisor PIPEs between the different SVM's. So one would have a TCP/IP SVM that provides the TCP/IP network stack to the outside world. A web server SVM that provides just the HTTP protocol and base set of applications, using a hypervisor PIPE to talk to the TCP/IP stack. Within the web server SVM, would use hypervisor PIPEs to talk to the individual application SVMs.
Linux-Vserver as well. It's even used in the OLPC.
l -Reprint.pdf
a lks.html - interesting bit: "The interesting thing about this by the way is, people are terrified of how are you going to do virtualization on a 466 Mega hertz CPU. With the Linux VServer, the overhead you pay is 32k per task struct, but there is 0% measurable CPU overhead with up to 65,000 virtual machines running . 'll let that sink in for a few seconds. It lets us do full network-stack isolation lets us completely isolate the filesystem, it lets us do this copy and write mode with just a twist on what immutable links do so we can actually do the said at no overhead on the file system. It provides various hooks which we can use, we can add scheduler bios for system services etc. directly on the kernel. There are no policies with this so the mental model is simple. We tell our application developers essentially, the mental model is that you are the only application executing on the machine and you can use a number of the interfaces that we provide to interface with the rest of the system but essentially, you are the only application running on the machine."
http://en.wikipedia.org/wiki/Linux-VServer
Virtualizing a system can be cheap if the correct virtual machine is chosen. For instance, Linux-VServer (http://linux-vserver.org/Overview) is a very cheap virtual machine that can be easily used to split a linux system into several separated security containers, each one running an independent application/service. It uses Copy-on-Write to share the same system files until one of the containers modifies the file. Only then the file is duplicated on disk, and even so only the modified blocks, so it is very cheap on resources.
This paper has an interesting description of Linux-VServer:
Linux-VServer - Resource Efficient OS-Level Virtualization - https://ols2006.108.redhat.com/2007/Reprints/potz
"Linux-VServer is a lightweight virtualization system
used to create many independent containers under a
common Linux kernel. To applications and the user of a
Linux-VServer based system, such a container appears
just like a separate host.
The Linux-Vserver approach to kernel subsystem containerization
is based on the concept of context isolation.
The kernel is modified to isolate a container into
a separate, logical execution context such that it cannot
see or impact processes, files, network traffic, global
IPC/SHM, etc., belonging to another container."
"While a typical Linux distribution install will
consume about 500MB of disk space, our experience is
that [with copy-on-write file system] the incremental disk space required when creating a new container based on the same distribution
is on the order of a few megabytes."
It is so cheap that even the OLPC laptop (not the most powerful computer on Earth...) uses it!
http://www.olpctalks.com/ivan_krsti/ivan_krstic_t
So the best way to abstract the application interface to the machine is to put a costly virtual machine around it. Thats awesome. I always thought that user-space options like Java, CLR, etc did a pretty good job at that at a very low cost, but I guess it just makes a lot more sense to duplicate the ENTIRE OPERATING SYSTEM for each VM. 32 meg to run the java vm was just too little memory- you need to boot up a heavyweight OS and consume 100 meg or so FOR EACH VM. That makes a whole lot of sense.
CPU virtualization is an interesting topic, but people implementing it are really stretching to find reasons because there are very few good reasons for it. It solves a lot of problems that aren't really that high a priority to solve and does so at a premium.
http://barrapunto.com/article.pl?sid=07/07/21/1720 204&threshold=-1&mode=nested#936649
http://translate.google.com/
I suppose you think when someone claims to be able to eat a horse, they actually have the capacity to devour an entire equine. Relax, it's a figure of speech.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
When the buzzword(s) of the day has been 'cross-platform' if we use Virtual Machines to encapsulate an application within it's own OS then the whole convenience of cross-platform apps goes out along with the bathwater. So will this give rise to the tailored OS, which is packed up alongside the application? I guess it would make it a whole lot easier on devs if they don't have to bother testing in anything more than one exact environment. (And I do mean exact - installing another unsupported app within the tailored OS breaks your EULA and Support Contract.) I suppose the snake would eventually eat it's tail with a base operating system that launched the child OS when you ran the application and gave it a seamless window interface. The real question here is how far it will go - and how many core's you'll need just to run a desktop pc...
Comment removed based on user account deletion
Wine does this but from an emulation point of view, it's not virtualisation I think...
Herve S.
The obvious explanation for Barrett's investment (which will net Intel a measly 2.5% of VMware's shares after the forthcoming IPO) is that Intel believes virtualization will cause people to buy more, not less, hardware.
No the obvious explanation is wrong. The percentage of hardware bought that will run virtual servers will continue to increase. Intel is protecting and trying to expand their market share. 'Here look at us, we make virtualization better.'
Companies will buy less servers then they would if virtualization did not exist. I know we are.
Many QA people, including myself, use VM as well. Very useful with buggy builds. The best part is sharing the image. I can send a copy of my image to a developer with the reproduced issues without having him/her to come over to see it on my real machine. We still use real machines for testing, but VM is useful.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
so why use it when words like Isolation and Encapsulation do the job very well???
How about just "containment". That way, rampant verbification won't overrunerrize things.
- First they ignore you, then they laugh at you, then ???, then profit.
It's the worldwide system of intermodal freight transport using ISO standard containers. It revolutionized shipping starting in the mid 1950s. You wouldn't be buying cheap Chinese crap at Wal-Mart without it. Perhaps the authors are trying to play on this connotation?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
is not consolidation (although that's popular with the CFO). In fact, I'd say personally it's not even the ability to build vastly more scalable and redundant infrastructures (although that's a close second). My favorite feature of virtualization is how much easier it makes life for sysadmins (a selfish perspective, but entirely valid, as sysadmins are the ones who will be doing the management work, whether it's on physical gear or virtual). Need a new server? Clone one from a template and you've got add'l compute capacity (CPU/RAM/net/disk) up and available and into the load balancer in 30 minutes. Compare that with the time required to bring a physical machine online (assuming you have what you need in stock, built and ready to be racked), cable it, configure it, install an OS (even with ghost, pxeboot, {kick,jump}start, etc.), and get it into production. Even if you're following all the great ideas from e.g. infrastructures.org regarding managing your physical infrastructure, it's still going to be an order of magnitude less scalable than managing VMs, blades (or non-blade servers), storage and network stuff from a single location (VirtualCenter, in the case of VMware VI3).
Virtualization lets admins finally treat their compute resources as a bucket from which they can allocate discrete amounts to projects or business units in an on-demand fashion (in fact, with a little work you can even do internal billing so that IT is no longer a cost center - the rest of the company can finally see how much, in dollars, they are consuming of compute resources that used to be provided "for free" by IT).
(the above is based on experience; the infrastructure my team built and designed last year was the world's largest production VI3 implementation when it went online fall 2006.)
illum oportet crescere me autem minui
I love that some guy made up this new buzzword. After all, there are no other words in existence today which can convey the same meaning!
:)
Well, except for compartmentalization which I guess has been used alongside words like virtualization & partitioning in computer science for ages.
Wouldn't the term "containment" be better? Why invent a word when a suitable one already exists - oh wait, this is the tech industry... ;)
-LLM
Annoy a Conservative...
Once everything is run through one or more virtual layers, direct access to devices through the drivers can be discarded in favor of controlled interfaces. This could enable high security abstractions such as being able to view DVDs without being able to subvert country codes or grab individual frames or being able to listen to music streams without the ability to capture the digital content that drives the audio. Perhaps virtualization could also be a strategy for a simple yet secure messaging sytem that could defeat spam?
Containerization is splendiferous! Its lengthitude and overlycomplicatedness is only outdone by its fakesoundiness and the lameiousity of its DonKingyness. Double plus good! I hope to see it in the 11th edition of the Newspeak dictionary.
If we were using an OS with decent memory protection and scheduling (VMS, among others), there would be no need to use an extra layer of software to run more than one task on one box. Back in the day, I supported several hundred users on each individual machine in a VAX cluster, doing everything from large finite element analyses, CAD for large engineering projects, large Oracle database activities, prgram development in several languages, word processing and office automation, and accounting and financial work large and small, all without the need to virtualize and give everyone a copy of an OS, with the attendant waste of memory and CPU that entails. People excited to be using virtualization to accomplish the same thing don't realize how absurd (however satisfactory it may be, given Windows) that solution is.
There is no God, and Dirac is his prophet.
Intel was spinning up its own virtualization play complete with security on the chip. TPM, virus scanning, backups of the flash, etc... They bought into the VMware offering as a hedge. VMware was lined up well with AMD and VMware failed to secure a deal with Intel on the desktop. From a pure numbers point of view desktops have more volume/potential. So server consolidation will be owned by MSFT (laugh now, but who is laughing the security space? not SYMC nor NAI) that is a given. VMware price points have dropped like a rock thanks to MSFT. So if INtel and VMware can drive increased demand for CPU, without reliance on an O/S (like MSFT) they both win. THis also means VMware is gearing up for some big acquisitions. That is what the cash is really for.
THat being said, VMware is a hog all around. CPU, disk, memory. It buys you security from failure/disaster but at a very high cost. Google doesn't use virtualization for a reason. For small shops its okay, but for major work it doesnt fly.
Allegedly, this is built into Solaris. It's called "zones", and is basically an own partition of the entire operating system.
However, as far as I understand, you can prelink some stuff and still reuse shared memory in shared libraries.
Also, I think what you're looking for can be found in the Jail-implementation of BSD.
However, the failure to contain a running application by regular means of a decent operating system is usually a good sign that something is really broken in the application. (A decent application is quite allright to run as it's own user, for instance.)
Containerization is nothing new. In fact, application isolation (that being the proper name) was a primary selling point for Win95, for MacOS5, for OS/2, for OS/2 Warp, for NeXTstep, .NET, for Java, and Geos. This is nothing new. The "consensus belief," if it really did forget about this aspect of things - about which I retain intense doubts - is just forgetting history.
StoneCypher is Full of BS
As a computer scientist I'd like to welcome you all to the near-40 year old world of virtual machines, hypervisors, and extreme flexibility. Tho I've only been using them personally for ~20 years.
Server CPU's have for all practical purposes always had VMs. Intel resisted adding the needed hardware support to it's consumer chips for a very very long time, to avoid exactly what we see happening now.
And yes, VMware rocks harder then a fox with socks.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
We have legacy financial applications running on Windows NT and original hardware. No one knows how to reinstall the applications, we don't even have all the source media, and there's no documentation. Some of the original vendors no longer exist. Aside from illustrating the advantages of open source, converting these old servers to virtual machines will let us keep them alive indefinitely. Or at least the time required by the statute of limitations. These applications haven't been used in years, but if the company is audited data will need to be extracted from the proprietary databases.
You really don't want to have your applications and their operating environment tied to specific hardware. Containerization is the only way to be sure we will be able to run Windows NT apps on modern hardware for which there are no NT drivers.
i do believe you have made a faux pas
this is meant to be a discussion on the subject of virtualisation and computers- whatever gave you the idea to use it as a platform for you next jihad!
We have an AS/400. It runs hundreds of programs and has many systems running at the same time. OS/400 can keep the various programs from walking on each other. We have about 500 users running programs at the same time. It also does e-mail, web serving, EDI, AS2, XML, Frame, serial, and TCP/IP communications, printing as a print server and can emulate windows print spooling. Has an SMB server (like Samba) as well as NFS. Acts as a SBM client with AD integration and SSO. The list goes on. It could run *NIX in an LPAR, and within that it can run X.
All that runs on one AS/400, with a second hot standby in a remote location.
We have over 50 Windows servers, each running ~1-2 applications.
It's the OS. Windows just isn't as mature yet.
How about let's just use existing words in the English Language:
...
Compartmentalize
Seperation
Isolation
Protection
- It's not the Macs I hate. It's Digg users. -
True. Bute you can throw Windows out of the virtual computers as often as you like.
... trying to reproduce problems. Snapshots are SO convient in VMware v4+, take a snapshot before the problem occur to skip all the steps before (e.g., install, configure, update).
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
I think the growing need for virtualisation as a safety/management measure reveals major flaws in the fundamental design philosophy of both operating systems and languages. Specifically, it is becoming abundantly clear now that our existing methods of breaking software into modular components simply don't work. If they worked, we wouldn't need to draw boxes around things at the physical or virtual server level in order to guarantee containment.
I think basically the problem is that our languages still think largely in terms of a single executable process, leaving interactions with hardware, files and other processes up to the operating system, while our operating systems are still mostly geared toward the old timesharing model: how to multiplex access to CPU and random access storage between multiple users. They're too low-level, too close to the hardware. Process tree, file tree, libraries, even component framework, all of these are angles of attack at the problem but not general enough to prevent nasty interactions between themselves - you can't, for example, safely create any kind of 'sub-system' or 'chroot jail' equivalent inside all of the filesystem, hardware, IP address, library/components, and process tree at once. But that's the minimum you need to be able to guarantee that you have a single, isolatable system that can deliver a service. A modern graphical desktop, for example, requires all of: libraries, executables, system config files, user config files, user data, an X server, a time service, a software patch/update service, network access (with ports non-firewalled), many little utility services like D-BUS, clipboard, etc. There's no way you can draw a box around all of those inside an OS with the tools we have now.
So, you boot up a virtual server and do a whole OS install, because you know that works. If you've got the time and a *very* specialised application, like webhosting, you *might* be able to get away with something less than full virtualisation - just virtualising the filesystem, for instance. But it's risky.
What we want is a much more general kind of computing metaphor that takes *a system of components* as a fundamental primitive and allows easy reuse and sandboxing of these as a matter of course. Something like a Plan 9 approach where 'everything is a file' at a radical level, including processes. There would need to be an integrated language that is based around parallel clusters of communicating file-like components rather than serial threads of execution. And make 'duplicate this system, but inside this functional requirements sandbox' be a very, very basic primitive (if not the lowest-level one of them all).
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Okay illiterate drone: put down the language and step away.
Surely the word "encapsulation" could be pushed into service here? What is wrong with these people?
I suspect it's another case of "blurt out the first thing that comes into your head" disease. Retards.
There have been several times when I've wanted to try some high-level OSS package for a quick test run. Some "Exchange Killers" come to mind, but never I've gotten beyond the install docs because there are literally 50 dependencies and who knows how many config changes required just to install the entire stack of software. Now, thanks largely to VMWare's free VMWare Server, there are tons of pre-configured builds for all of the major OSS applications.
It really brings down the knowledge and time required for these things. Even backups become a simple task that can be handed down to a non-techie -- just create a VM snapshot and copy it like any other file that is backed up.
Is this Containerization? Yeah, kind of. I've always thought of it as abstracting away the OS and drivers. Many people would freak out if I tried to install a Linux box in their office. But a Linux "application" in a VM on a Windows box? Not scary at all.
Containerization was well established in the market long before vmware even came into the picture. Read about Solaris Containers, AIX Wpars, and linux containers. AIX Wpars, in fact, allows you to move an entire application-application-server-database-driver stack from one machine to another on the fly with 0 downtime.
I remember when we first got VM/CMS back when I was an undergrad - I could now allocation a whole megabyte of virtual address space, which made it possible to crunch bigger matrices for engineering problems.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks