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.
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.
“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 ([email protected]) (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
#
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?
… or maybe from NetBSD, since it also can do that:
http://www.netbsd.org/docs/guide/en/chap-linux.html
Nope. Sun’s solution is based on their containers technology, which is totally different.
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:
P.P.S. Both Solaris’s LXRun and FreeBSD’s BrandElf seem to have the same origin. From FreeBSD’s man pages
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.
From my original post
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.
From my second post
I was not under the impression that the BrandZ system was a binary compatibility layer like wine. As far as I can tell, it’s based on OS virtualization. Nothing like Wine.
I still can’t see how you could have miss understood what I was saying if you had actually taken the time to read my posts.
It is. It is not true OS virtualization, at least, it isn’t virtualizing Linux anyway. In other words, the Linux kernel isn’t actually running inside the container. Instead, a GNU/Linux environment is running inside a specially branded Solaris Container that translate Linux system calls into the Solaris equivalents, etc.
As I mentioned before, since you did not clearly state that you were referring to LXRun, I assumed you were talking about the binary translation that BrandZ provides since that is what this article is about.
Edited 2007-08-28 19:09
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…
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?
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
“1) Their customers asked for this”
They did? I seriously doubt it. Sun, having lost dominance in the hardware business to the likes of Dell and HP (and IBM), needs something to avoid becoming just another hardware vendor. That something is Solaris.
Their customers are going the Linux way just like everybody else’s customers. Why the hell someone would ask Sun to support Linux applications on Solaris if they can just go for the real thing? (And if you are willing to risk all sorts of trouble with this “emulation” stuff, why not risk less with one of the free Linux distros even…?)
This is just Sun trying to catch the Linux wave while still keeping their “Solaris is the real UNIX” position.
“3) Containers have advantages that hardware virtualisation does not provide”
And that’s why you should just go for OpenVZ if you really need Linux applications running inside containers.
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
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
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.
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.
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…
Not to be an ass or something but maybe that is because Linux 2.6 tend to be completely different in various parts for each version? I guess it’s hard to implement whatever way Linux decides to function this and that month ..
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.
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.
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
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.
<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.
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.
Why? What’s the point of running Linux applications inside Solaris…?
Many applications (including closed-source ones) are designed to work with linux, so they won’t run on solaris.
With this thing Sun is only encouraging people to not port apps to solaris and make linux even more relevant, but that’s another story.
“””
“””
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. 😉
Hehe – because they can
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
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.
Especially x86 version of solaris.
It seems that no one wants to help sun improving their opensolaris acceptance.
Not just vmware but alot of developers do not support sun now. It’s really sad!