When Solaris Containers for Linux Applications is released into the source code with Update 4 on Aug. 27, Sun customers will be able to run unmodified Linux binaries made for Red Hat Enterprise Linux and CentOS. Formerly called BrandZ, Solaris Containers for Linux Applications is an upgrade to the Containers operating system virtualization technology already included in Solaris 10. The update will be released at no charge to existing Solaris customers.
Post a Comment
Member since:
2006-12-28
Solaris containers are a god send when dealing with the proper distribution of resources for server applications.
Although it's not a virtualization solution in the classical sense of a Hypervisor, it gives you a similar option that, although sacrifices flexibility (especially in the number of operating systems supported), has very little of the performance trade off commonly associated with tradition virtualization solutions.
Not only does it help isolate applications from one another, it also enables a sysadmin to rapidly roll out multiple instances and/or restore from backup without having to take a machine down. It's also fantastic for setting up test environments.
Although you could already run Linux binaries using a translation layer similar to what Wine does for Linux, the ability to compartmentalize a full Linux distro is, IMO, a brilliant new feature of whats already a fantastic enterprise OS and although the article mentions that the system is not intended for the running of more than one or two applications yet to be ported to Solaris (if ever), the future could see a much more advanced implementation.
The only thing that bothers me about this whole issue is the way that SUN constantly goes from hot to cold and back again when dealing with Linux. One month, Linux is 'da bizz', then suddenly it's some upstart hellspawn. Just take the following quote from the article
Still, kudos to SUN and the OpenSolaris project for some great software.
Member since:2006-11-18
"Although you could already run Linux binaries using a translation layer similar to what Wine does for Linux"
This is what FreeBSD does using Linux Binary Compatibility: http://freebsd.org/handbook/linuxemu.html
an example:
% ./linux_binary
ELF interpreter /lib/ld-linux.so.2 not found
% brandelf -t Linux ./linux_binary
% ./linux_binary # runs same as in Linux
You can also have a whole Linux running under FreeBSD in chroot for example:
# mount_linprocfs linprocfs /usr/compat/linux/proc
# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1d on /tmp (ufs, local, noatime, soft-updates)
/dev/ad0s1e on /var (ufs, local, noatime, soft-updates)
/dev/ad0s1f on /usr (ufs, local, noatime, soft-updates)
linprocfs on /usr/compat/linux/proc (linprocfs, local)
# PS1="$ " chroot /usr/compat/linux /bin/bash
$ uname
Linux
$ cat /proc/version
Linux version 2.4.2 (des@freebsd.org) (gcc version 3.4.6 [FreeBSD] 20060305) #4 Sun Dec 18 04:30:00 CET 1977
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 7
model name : AMD Athlon(tm) XP 2000+
stepping : 1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm
cpu MHz : 1666.73
bogomips : 1666.73
$ exit
#
Member since:2006-12-28
I could be totally wrong, but I get the feeling that if not a complete rip off, then the SUN Linux binary compatibility layer is at least heavily influenced by and probably uses code from the FreeBSD implementation. Mind you, I gotta do some checking on that so don't quote me ;-)
Anybody else know anything about this?
Member since:2006-11-18
... or maybe from NetBSD, since it also can do that:
http://www.netbsd.org/docs/guide/en/chap-linux.html
Member since:2005-07-06
Anybody else know anything about this?
Nope. Sun's solution is based on their containers technology, which is totally different.
Member since:2006-12-28
I was talking about the Linux binary translator, LXRun, not SUN's new container technology.
Maybe you should actually read my post before commenting on it?
P.S. From the LXRun FAQ:
A: It was originally written by Michael Davidson, an engineer at SCO.
In 1997, Michael released the lxrun source code to Steven Ginzburg who is continuing its development as an open source project under the Mozilla public license. Contributors to lxrun have included hobbyists and engineers from all over the world. In addition, the Santa Cruz Operation (SCO) and Sun Microsystems have both contributed engineering time and other resources to the project.
P.P.S. Both Solaris's LXRun and FreeBSD's BrandElf seem to have the same origin. From FreeBSD's man pages
The Santa Cruz Operation, Inc., System V Application Binary Interface,
April 29, 1998 (DRAFT), http://www.sco.com/developer/devspecs/.
Member since:2005-07-06
Maybe you should actually read my post before commenting on it?
I did read your comment. You never said LXRun. Since this story was about BrandZ, etc. I took meaning from what you said based on the context.
lxrun is not used for the basis of BrandZ, BrandZ is a different beast from everything I have read and seen in the code.
Member since:2006-12-28
Member since:2005-07-06
From my original post
Although you could already run Linux binaries using a translation layer similar to what Wine does for Linux...
Does your original post contain the text "LXRun" anywhere? No. Therefore, in the given context, I assumed you were talking about the syscall translation layer build into BrandZ since the context of the conversation was about BrandZ.
Member since:2005-07-08
I enjoyed this little nugget from Sun's website:
Solaris 10 effectively becomes the premier platform for developing, testing, and deploying Linux applications.
Right... A 4-year-old Linux userland ported to a non-native kernel is better than the real thing. Developing and testing Linux applications on a system that kinda-sorta complies with LSB 1.3. Seems like a leap of faith to me.
Don't get me wrong, this is very useful for running the odd proprietary Linux application that isn't available for Solaris. I'm a staunch supporter of interoperability, even if it isn't 100%. But to suggest that Solaris is now the premier Linux platform is like saying that Mono is the premier .NET platform. They're both a couple generations behind and have their fair share of gotchas.
From a design perspective, I question the use of OS virtualization to provide non-native OS support. I mean, the nature of the beast is that OS-level virtual machines share a common OS. In a containerization frenzy characterized by the misuse of hardware virtualization, Sun makes the opposite mistake.
There were a number of false starts
This is another one, IMHO. Sun, the proper way to support multiple platforms on the same box is... (drumroll please) hardware virtualization. Yes, this is a rare chance to use it appropriately. Finish the Xen dom0 port you've been working on, or better yet, implement the KVM strategy in the Solaris kernel.
Slightly OT: Check out Glick. It's the most interesting application bundling approach I've seen:
http://blogs.gnome.org/alexl/2007/08/07/experiments-with-runtime-le...
Member since:2006-12-28
Corporate crap talking is always worth a good laugh IMO, well pointed out :-).
As far using hardware virtualization as a better solution for Linux virtualization, I agree with you. I would rather see hardware virtualization integrated within the BrandZ framework though as, frankly, too many frameworks make for annoying administration.
Still, In time, who knows what other Solaris virtualization solutions will be provided. The questions are, are they gonna be any use?
Member since:2005-07-06
1) Their customers asked for this
2) They are doing virtualisation, this is just another solution
3) Containers have advantages that hardware virtualisation does not provide
Usually I agree with your posts, but you are way off the mark here.
You seem to believe there is only "one proper way" to do things. There is not. There are many ways to provide solutions to the same problem. Solaris Containers are just one of many solutions.
Sun is giving great value to their customers by providing them with multiple solutions so customers can choose the solution that best meets their needs.
Oh, and by the way, Ian Murdock thinks brandz is great. So there's a list one well-known Linux-affiliated person who likes them. if you say, "He works for Sun, so of course he would like them!" -- you'd be wrong. He's already indicated many things Sun has that he does not like.
Edited 2007-08-27 19:43 UTC
RE[3]: SUN flip flops yet again.
Member since:2005-07-08
Look, I have nothing against Containers. In fact, I think that OS virtualization is the better solution for most of the typical use-cases for hardware virtualization. If your workloads can deal with a common platform, then by all means go with the lightweight solution.
But Branded Containers tries to use OS virtualization for the opposite situation, where you need different platforms for different workloads. Sun doesn't (to my knowledge) have a hardware virtualization solution, so they aren't providing choice, they're doing the best they can with what they have. And like I said, interoperability is good even if it isn't perfect.
If I could pick only one kind of virtualization to use on my platform of choice, it would be OS virtualization. But if I had to pick only one kind of virtualization to offer my customers, it would have to be hardware virtualization. How would Sun implement a Windows Branded Container? I'm not sure that's technically feasible.
Edited 2007-08-27 20:14
Member since:2006-12-28
Wow Butters. It seems to me you not only want your cake, you want to eat it as well! ;-)
Seriously, I get where you are coming from but honestly, I think you need to chill. Sure, these solutions may not meet your idea of a good engineering solution but personally, I have yet to encounter an engineers perfect world.
You seem not to keen on how virtualization is currently used as the IT solution for all you're diversification needs, but guess what? I have yet to encounter the kind of screwed up, mess up scenarios you keep hinting at. Sure, its tauted as the latest gratetest but so is every other 'new' IT innovation in this stagnant industry.
I personally welcome any and every alternative attempt at solving an issue as, just like with FOSS, generally the more competition, the healthier the ecosystem.
Again, just my €0,02
Member since:
2006-07-24
I was all on board for this back when it came out for OpenSolaris, however I soon found out it only supports distros with 2.4 kernel..... Which as far as red hat goes, thats rhel/centos 3.x.
To bad, would be a great feature if I could run rhel/centos 4/5.
I tried to flip through the forum/community section but it still looks like this is the case.
Member since:2005-07-08
Questions concerning BrandZ can be answered here:
http://opensolaris.org/os/community/brandz/brandz_lae_faq/
I only played with it for a limited time, but BrandZ worked well enough for me to install and use CentOS 3 on one of my test machines running the Beta for what will more than likely be called Solaris 10 9/07.
Member since:2006-11-18
FreeBSD 7 uses 2.6.* [Fedora Core 6 as base] for Linux Binary Compatibility, more info here:
http://www.freshports.org/emulators/linux_base-fc6
http://ivoras.sharanet.org/freebsd/freebsd7.html
http://wiki.freebsd.org/linux-soc2007
http://www.freebsd.org/news/status/report-2007-04-2007-06.html#Linu...
Member since:2005-07-23
Member since:2006-10-12
Last I looked, glibc attempted to be pretty agnostic, kernel-wise. You'd build it against current sources, but it figured out at runtime what kernel version you're running against (as well as a certain amount of feature detection by other means).
I looked a while ago, though—it's been a couple of years since I did any libc-level hacking, and things might well have changed, though I'd be relatively surprised.
Binaries from a 2.6-based distribution would more than likely run fine, but you've got things like procfs being different between kernel releases. Beyond that, Sun's only going to support 2.4.x-based stuff, but that doesn't mean people won't run 2.6.x-based stuff completely successfully.
Member since:2005-07-08
The linux syscall interface is stable. Binaries that did run on 2.4 run in 2.6 with no modifications. You must have mistaken, like many other people does, the internal kernel API/ABI with the syscall interface - the one that matters, because the other are, like the name says, "internal".
Now, there're new features in linux 2.6 that are not available in 2.4. So a program using those features will not work in a solaris container that only implements linux 2.4 functionality. But that's due to the addition of new features, like any other operative system does, not because it's hard to implement whatever way Linux decides to function this and that month - which is what your FUD post tried to say.
Member since:2005-07-06
Bzzt. Wrong. The syscall interface may not change, but the other interfaces that the kernel provides certainly do.
Even then, there are certain things that were changed in the 2.6 series that have to do with public interfaces.
See this thread for some of the issue that are being faced:
http://www.opensolaris.org/jive/thread.jspa?messageID=99098
Member since:
2005-07-13
sun is playing this smart. they think they have a better system and want he linix crowd to give it a try. why not make their apps work on solaris as insentive. this is incredibly helpfull for business users. sun is making a lot of good moves here. i cant wait for a real polished user friendly solaris release in the near future.
Member since:
2005-07-06
<oftopic>
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 12
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 2200.166
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up ts fid vid ttp
bogomips : 4403.04
clflush size : 64
$ cat /proc/version
Linux version 2.6.23-rc3-gd1caeb02-dirty (******) (gcc version 4.2.1) #3 SMP Sat Aug 25 18:20:07 CEST 2007
</oftopic>
Would be great to run any kernel and userland in BrandZ though.
Member since:
2006-10-12
Yes, the BSDs can do binary emulation—with or without chroot or jails (a Linux jail is rather cool indeed—but you're not by any means limited to Linux, especially not on NetBSD), but jails aren't a patch on Solaris Containers in terms of management and flexibility.
I wouldn't be at all surprised if the features of Containers start showing up in DragonFly, though.
Member since:
2006-01-03
Member since:2005-07-08
Member since:2005-07-24
"""
"""
I hadn't thought of that. It seems funny being on this side of *that* fence after hearing the same observations about Linux and Wine all these years. ;-)
Member since:2006-06-26
Member since:
2007-07-27
On my x86 OpenSolaris I have installed CentOS Linux in a dynamical growing slice on ZFS. I have configured it and "locked" it via a snapshot, it takes 0.5 sec to do a snapshot. Now I can clone the Linux installation and deploy a new Linux Clone in 0.5 sec. If I install Oracle in a clone, only the Oracle files will be installed in that clone. Everything else is read from the master Linux installation. Each clone lives on a separate dynamical growing slice, and I can make a snapshot in 0.5 sec - as many as I like (one guy had 64000 snapshots using 2.3GB disk space). Each clone, aka BrandZ, has it's own IP address. This way I can have a version of Apache in one BrandZ, and another version in another BrandZ. I can destroy a BrandZ (delete it's slice) in 0.5 sec and I can recreate it again, just as quick.
Each Brandz uses typically 50MB RAM and 100MB disk space. The BrandZ is designed to be very safe, if a user gets root access to a BrandZ, he wont get out to the global Solaris OS. All BrandZ uses the same kernel; the Solaris kernel. The Solaris kernel is rock stable and it isnt likely to crash. This makes it a very light weight virtualization. Having like 50 BrandZ running, takes ca 1-2% CPU utilization. I think Ive read that one guy started 1000 brandz in 1GB RAM. The maximum nr of BrandZ running is 8192.
Of course, I have done this with Solaris too. This way I can have different patch levels on several Oracle installations if I wish. All running simultaneously. I have cloned the original Solaris OS and made clones, aka Zones. I am thinking of letting all users have a separate Zone, with root access. If he messes up, I destroy and recreate the zone, which takes 0.5sec + 0.5sec. The user has a home directory on a dynamical growing slice (file system via ZFS), also the Zones and BrandZ has it's own file system. This way I can make a snapshot easy. And rollback too if I wish. I can install Java Enterprise System in one zone, and make a snapshot and deploy a copy in 1 second. And I can rollback whenever I want.
I say; I like this. Very much.
also solaris zones
Member since:
2005-07-07
You get the ability to choose ZFS as your underlying filesystem and the ability to DTrace your application from the global zone.
As it's implemented at the syscall layer, there is a set of specific linux system cal probes, in addition to the other already available ones.
Most things that you would find performance wise will also improve things if you move your application back to a linux.
Surely interoperability like this helps everyone?
Tp.
Member since:
2005-07-06
