XenServer 6.2 Is Now Fully Open Source 86
First time accepted submitter Jagungal writes "Although the core Xen hypervisor has always been open source from the start, Citrix have now released the next version of their XenServer including all features and tools under an open source license. This includes also introducing a new XenServer.org community portal. The major change for users is that they now get all features from the licensed version for free but unless they pay for support, they have to do all security updates manually. Change logs for the new version 6.2 can be found here.
It's been a few years since Citrix started giving it away, free as in beer.
we ditched vmware for xenserver 2 years back... (Score:5, Interesting)
and it was the best choice we ever made.
live migration is free (as in beer). and it runs its little heart out with no problems.
2 years now, 30 TB of files, 40 GB of mysql data, about 30 VMs on 4 hosts. not one single problem.
The only issue we've run into is getting fully paravirtualized FreeBSD. It is a rather involved process. But once you have one VM you just copy it like a template. And luckily ZFS On Linux is starting to be good enough so we don't have to really care about FreeBSD so much.
Plain-vanilla Xen (not Xenserver) with DRBD (et al.) making instant failover is pretty awesome too.
Fuck VMWare.
Define open source (Score:5, Interesting)
According to
http://www.xenserver.org/about-xenserver-open-source/gplv2-license.html [xenserver.org]
the licenses used include:
AFL
Artistic
ASL 2.0
BSD
BSD-like
LGPL (v2+, v2.1 , v2.1+, v3+, v2+ with linking exception, with linking exception)
GPL (v2, v2+, v3, v3+, unspecified version, v2 with linking exception)
OSL
MIT (v1.1, unspecified version)
OpenLDAP
Zlib
PSF
That list also includes:
Qlogic (link is to http://www.qlogic.com/supportx0/agreement.asp [qlogic.com] , but that's borked)
Public Domain
pubkey (artefact; refers to GPG keys for some reason)
Proprietary
Distributable
Freeware
I'm just a simple hyperchicken lawyer from Andromeda, but in my galaxy, proprietary licenses aren't 'open source' let alone Free software licenses. Same goes for freeware, public domain, etc.
For the curious, the proprietary-licensed stuff includes software from Brocade Communications, Citrix Systems (!), Emulex, and QLogic.
Re:we ditched vmware for xenserver 2 years back... (Score:1, Interesting)
and it was the best choice we ever made.
I went the opposite direction. We had been using exclusively Xenserver.... then at some point VMware released a free edition of ESXi; this is huge, and we tested it and found many advantages.
Eventually, we ditched Xenserver. For the past few years we have been using VMware vSphere, and ditching Xenserver was one of the better choices we ever made.
3 years now. 20 Tb of files; 6 TB of Exchange mailboxes, 500 GB of SQL Server and MySQL data, >1000 transactions per second , 16 to 1 consolidation ratio, with CPU, Memory, and Storage heavily oversubscribed; 280 VMs on 3 hosts, and no issues..
See? Other people can do that too...
Re:we ditched vmware for xenserver 2 years back... (Score:5, Interesting)
The Zimbra Open Source Edition is probably a very good choice.
- 99% of all companies don't need features then the open source edition.
- it supports large mailboxes very well. ( some of our employees have 21gb mailboxes, it still runs smooth )
- You can buy a plugin for encryption if you really need it.
- Mail (IMAP), Calender (iCal) and adressbook (LDAP) sync is possible to almost any device.
- You can always get the commercial version if you need the extras.
I don't think you can remotely wipe your mail using an open source product but nowadays you might simply get any android of iphone device and use a wiping app. Maybe not as convenient but it works.
Spamassasin can work very well ( it certainly does for us ) using external blocklists and distributed mail analysis services ( dcc, razor2 ) in addition to it's core filters. We added greylisting as well. Everything runs as part of the Amavis product. We don't use Bayesian filtering though. While good on paper we found it to be to unpredictable in real life. ( people reporting valid mailing lists as spam instead of unsubscribing, etc ) Instead we added around 15 additional custom spam filter lines over the years but that's it. Now all our spam is gone. We filter mail for over 1500 domains and our customers have never been happier.
ganeti (Score:4, Interesting)
Check out ganeti as well: https://code.google.com/p/ganeti/ [google.com]
Features
Ganeti provides the following features for managed instances:
Support for Xen virtualization:
Support for PVM and HVM instances
Live migration support
Virtual console (on PVM) or VNC (on HVM) to control instances
Support for virtio or emulated devices
Support for KVM virtualization: (from Ganeti 2.0)
Live migration support
Support for fully virtualized instances
Support for semi-virtualized instances (kernel residing on the host)
Support for VNC or serial access
Support for virtio or emulated devices
Recommended cluster size 1-40 physical nodes
Disk management:
Plain LVM volumes
Files (from Ganeti 2.0)
across-the-network raid1 (using DRBD) for quick recovery in case of physical system failure
Instance disk partitioning supported from Ganeti 2.0
Export/import mechanism for backup purposes or migration between clusters, or
Automated instance migration across clusters (since Ganeti 2.2)
Re:we ditched vmware for xenserver 2 years back... (Score:2, Interesting)
So spamassassin uses a lot of CPU? Have you seen the resources an exchange DAG requires?
Yes. I have, and Spamassassin/Amavis is orders of magnitude more expensive CPU-wise. This is probably due to the very massive amount of spam being attempted, and the inability of RBLs and tools such as DCC and Vipul's razor to effectively divert them, before Spamassassin starts chugging away at massive concurrency.
All the more bothersome, when some domains want "wildcard forwarding rules", so brute-force spam attempts at a domain fire off hundreds of messages.
If by enterprise grade, you mean "good enough for an ISP to use", then open source does just fine with a bit of tweaking and fine tuning.
No. I mean good enough to satisfy Enterprise users, and managers of Enterprises, such that they are satisfied of the features, performance, capacity, availability guarantees, and user experience that they have no benefit to running their own mail server.
This by the way includes rapid failover capabilities of all mail-related operation, load balancing, spam filtering, and prevention of "misbehaving users or devices" from adversely effecting server operations -- (per user throttling).
There is Non-MS, Non-GUI technology that might provide many of the things. But at the end of the day What the users want matters more. If the end user is insistent on features that can only be provided by a GUI-based server solution, then that is probably what they will be getting.
Well for starters, ditch Sendmail, use Exim, and then implement DRBD with linux HA
Not happening. Well-justified hate relationship developed with Exim over the years, due to MTA induced failure after failure on large shared hosting deployments, poor logging, and general lack of simple configurability -- I think perhaps the only Linux mail server software to suck more than Exim is QMail; they are pretty much at the same level.
Postfix, on the other hand is great.
DRBD with linux HA
The problem with DRBD with Linux HA; other than the fact that only a unix guru can maintain it and safely execute a disaster recovery (which 98% of the engineering staff are not qualified to do, and the portion that think they are qualified but are not are the most dangerous), is that DRBD doesn't meet acceptable standards of robustness, and requires manual attention in the event of a failover, and for failback: it's active/passive, and failover can really only be leveraged safely in the event of a catastrophe.
In other words: DRBD in its current form is only really suitable to be used as disaster recovery type system, not a host failure response type system.
In testing DRBD has proven to be unreliable in various failure modes, we would wind up with damage to data caused by DRBD itself, or operator error trying to get the failback to work like it's supposed to after a split-brain incident. Also, anything reliant on fencing by "killing" another server externally is not acceptably sane -- robust clustering systems utilize self-fencing nodes and provide additional methods of making quorum.