Slashdot Mirror


Novell Defends 'Unstable' Xen Claims

daria42 writes "Novell has fired back at Red Hat's claims that the open source Xen virtualization software is not yet ready for enterprise use. 'We had all the major hardware partners that had virtualization hardware like IBM, Intel and AMD. They all stood up and said "Yes, this technology's ready, and we fully support deployments based on Xen and in combination with SUSE Linux Enterprise 10."', Novell's chief technology officer said today. 'So I guess the other vendors would not do that if it weren't ready.'"

30 of 132 comments (clear)

  1. US-based startup? by TheRaven64 · · Score: 4, Interesting
    From TFA:
    Xen, primarily developed by US-based start-up XenSource
    Looking at the XenSource web site, they have three offices, two in the US and one in the UK. Considering that they are a spin out from Cambridge University (in the UK), developing software originating in Cambridge University, calling them US-based seems highly misleading.
    --
    I am TheRaven on Soylent News
  2. Of course its unstable by LiquidCoooled · · Score: 5, Funny

    Opening a portal to Xen could cause a resonance cascade.

    Dr. Isaac Kleiner has been warning us about this for years.

    --
    liqbase :: faster than paper
  3. Summary is incomplete by kripkenstein · · Score: 5, Informative

    Besides Xen, a few other interesting tidbits appear in the article, but are missing from the summary (and, were also missing in the post on Digg... suspiciously).

    1. All desktops in Novell have been using OpenOffice for a year now.

    2. 80% of desktops in Novell now use Linux (I presume the remainder use Windows).

    3. The article mentions some explanations for the recent personell changes in Novell. Not much content, though, just "we are in a different place now and need different people" (where have I heard that before).

    1. Re:Summary is incomplete by TheRaven64 · · Score: 5, Informative
      All desktops in Novell have been using OpenOffice for a year now.

      This is very important. Novell is the second largest contributor to OO.o (behind Sun, who still do about 80% of the work). Unlike Sun, however, Novell is primarily working on dogfooding issues. People within their organisation say 'I need this feature,' and they implement it. Better VBA support, for example, is a Novell focus area. They also work a lot on the UI and are responsible for the new build system (I'm not sure if that's in the trunk yet) that makes it much easier for new developers to get involved.

      --
      I am TheRaven on Soylent News
    2. Re:Summary is incomplete by FictionPimp · · Score: 2, Interesting

      Now if we could only get them to support their novell client on distro's other than suse.

  4. Senior VPs should not be allowed off their leashes by flipper65 · · Score: 4, Insightful
    While it pains me to say anything good about Novell in their current incarnation, Xen absolutely rocks. What RedHat's mouthy VP should have said, and could have reasonably said is: "WE have not fully tested Xen and WE are not ready to support it in the enterprise." That is a completely reasonable statement and probably better reflects reality.

    See what happens when you have VPs snooping around the engineering cubes and trying to redeliver what they thought they heard.

  5. Editing the headline by Anonymous Coward · · Score: 4, Insightful

    Hey editors, the phrase you are looking for is "defends against claims" or "defends Xen stability"... it is RedHat who should be defending the claims of instability. The object of "to defend" is the thing you are protecting!

    Muttering comment to self: why does English usage keep rotting out to the point where any short concise statement is often made 100% contrary to its intended meaning? If we have to decide everything by context and intuition, why not just have everybody say, "statistically appropriate speach act" as a placeholder? (Or "statistically inappropriate speach act" if we want to go with a nudge and a wink.)

  6. Red Hat's fault by KiloByte · · Score: 5, Insightful

    Well, Red Hat is right in some point: indeed, Xen won't work well with Red Hat systems.

    But, no one said it's Xen's fault. It's just the fact that cramming ten virtual machines into a single system is not a good idea when the minimal install is 1.2GB like with Red Hat's latest offerings, crawling with memory-hungry daemons. I keep whining on Debian's mailing lists about unneeded cruft like inetd or portmap in the default system, as IMHO 100MB is way too bloated. And 100MB, is, well, a bit less than 1.2GB.

    (Disclaimer: the figure of 1.2GB is something I vaguely remember reading about on /., I haven't touched Red Hat in >3 years. But if at the time it was the mother of all bloat, I doubt the situation has changed.)

    There is a similar case with Oracle. The default minimal install takes 800MB _RAM_ for a single instance, experienced DBAs claim you can go down as low as 300MB. MySQL is functional in 32MB, and shines in 64MB -- more memory is needed only if the dataset is big. For 34 databases on my old non-partitioned server there is only one over 100MB and three over 10MB -- I guess this is the typical distribution.

    Neither Red Hat nor Oracle are capable of scaling down; Xen is worthless if you can't trim down your virtual machines.

    --
    The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    1. Re:Red Hat's fault by marcello_dl · · Score: 2, Informative

      In fact, my leased 2.6.11-xen vserver with debian has performed well since when it was installed, 47 days ago. No X11 stuff on it, of course.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    2. Re:Red Hat's fault by walt-sjc · · Score: 3, Informative

      the fact that cramming ten virtual machines into a single system is not a good idea when the minimal install is 1.2GB

      Um, considering that in VM situations, most of that 1.2G can be in a shared read-only partition (or an LVM2 RW snapshot), and that modern hard drives are quite large, I respectfully disagree.

      See the LVM HOWTO which SPECIFICALLY mentions XEN as an applcaion of RW snapshots.

    3. Re:Red Hat's fault by _typo · · Score: 2, Informative

      My computer is running fine networked without inetd/portmap. So are my servers. Inetd is only needed for services that don't do their own daemon and these days that's pretty much none. Portmap is used for RPC so if you're running NFS/NIS you might still need it but it certainly isn't a standard thing either these days. Distros should not enable these by default since they're very much corner cases now.

      --

      Pedro Côrte-Real.

    4. Re:Red Hat's fault by vadim_t · · Score: 2, Insightful

      But we're talking about the default system here. inetd isn't required to boot the system, and you can perfectly have a fully functional system without it. That's not to say that it shouldn't be present, just that it shouldn't be installed until you install something that depends on it. Same for portmap.

    5. Re:Red Hat's fault by KiloByte · · Score: 3, Informative
      Um, considering that in VM situations, most of that 1.2G can be in a shared read-only partition (or an LVM2 RW snapshot), and that modern hard drives are quite large, I respectfully disagree.
      And what if you want to add a package to only one of the VMs?

      I put things into separate Xen domains nearly only for security. Having potentially vulnerable crap like php or python on only a single VM means that only that single VM will be endangered when a new hole is discovered. And when you don't have even things like wget installed, most attackers who pwn you will move to an easier target. Not to mention that I would want to see the face of that script kiddie once he notices the box has only IPv6 connectivity :p

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    6. Re:Red Hat's fault by walt-sjc · · Score: 2, Interesting

      And what if you want to add a package to only one of the VMs?

      Then you add a package to that VM. That's what RW snapshots allow you to do. Go read the LVM howto that I referenced above. If you want to delete a package, go ahead and delete a package. It really IS that simple.

    7. Re:Red Hat's fault by lewp · · Score: 2, Funny
      Yeah, you can, but what's the point? GUI belongs on a workstation, not on a server.

      You obviously don't work for Oracle.

      --
      Game... blouses.
  7. Press conference at the schoolyard by Rob+T+Firefly · · Score: 4, Funny

    Red Hat: "Is not!"
    Novell: "Is too!"
    Red Hat: "Is not, not, double not!"
    Novell: "Is too, no backsies!"

    More on this story as it develops.

  8. Seems Odd... by lefticus · · Score: 4, Informative

    Seems odd that Novell would "Fire Back." Unix Shell, where I host my server, has had no end of troubles with Xen. Personally, I have been mostly stable, and the Xen technology is an awesome thing. However, the message on the front page of Unix Shell "Due to lack of Datacenter space, unixshell# has suspended ordering until further notice" is not entirely accurate. If you read the forums, they are waiting until Xen is stable enough to be able to deploy further accounts.

    1. Re:Seems Odd... by widesan · · Score: 2, Informative
      Seems odd that Novell would "Fire Back." Unix Shell, where I host my server, has had no end of troubles with Xen.

      [...]
      the message on the front page of Unix Shell "Due to lack of Datacenter space, unixshell# has suspended ordering until further notice" is not entirely accurate. If you read the forums, they are waiting until Xen is stable enough to be able to deploy further accounts.


      I thought the same thing when I saw the summary. However, unixshell# uses some features of Xen pretty heavily that it seems everybody else barely touches. (see post #8 in this thread for details) I believe that there are many people using Xen without problems because they never hit those bugs. That's not an excuse for bugs, they still should be fixed, it's just that unixshell# is finding some obscure ones.


      In fairness to unixshell#, they are offering to migrate servers to their sister company, and they seem to be very forthcoming about the status of their servers. It seems that they are experiencing *occasional* lock-ups and reboots. Some people don't care, others do, and have left. They are actually out of space. It seems that they ordered another server, and were told that there no room by the data center. No warning at all. There are some other public incidents involving the data center's service and unixshell# seems to be reconsidering their choice of data centers. They appear, also, to not be worried about expanding until the Xen bugs are fixed. I don't blame them, more buggy servers means more headaches for the admins.


      I just wanted to offer a counter opinion, both Xen and unixshell# have operated above my expectations so far. Xen is a relatively new technology, I expect there may be some hiccups here and there. Until now, I have been fairly lucky.

      widesan:/$ uptime
        16:52:04 up 89 days, 8:58, 2 users, load average: 0.09, 0.04, 0.01
  9. I agree with them by codepunk · · Score: 3, Informative

    In my experience with it so far it is extremely stable and reliable and hell I am
    even running it on a redhat platform....the guests are all ubuntu not sure about redhat
    stability while running as a guest.

    --


    Got Code?
  10. Xen rocks? I don't think so. It just barely works. by postbigbang · · Score: 3, Informative

    The implementations between OpenSUSE 10.1 and the new SLES are different, and neither work. In OpenSUSE, the scripts are wrong, leading to difficulties in getting GRUB to boot it. Go past that and we could only get two paravirtualizations to work concurrently, this on very seriously built hardware (Athlon 64 with 12GB DRAM at 3.2GHZ). We tried it on other servers in the shop and had similar problems. Occasionally, instances would go incommunicado-- that's right, living but deaf and dumb to the point where we had to scrape them because (we believe) the hypervisor lost its place.

    No one we know has been able to get SUSE's version to work. It seems to be a branch of Xensource's work, but we can't get the source to try and hammer it out.

    We're neither Red Hat or SUSE lackeys, but it would have been nice to have a kewl distro that allowed something beyond SELinux, which has its own heartburn problems.

    --
    ---- Teach Peace. It's Cheaper Than War.
  11. Xen is in (Red Hat's) Fedora Core 6 Test 2 by hey · · Score: 3, Interesting

    announcement
    There must have been some issues.

  12. Re:Novell more unstable than Xen by lordeldor · · Score: 2, Informative

    I don't think Novell needed to have any assistance acquiring SuSE. Novell has for many years thought that linux was the tool with which they could make inroads on the desktop market. Not only that, they had been firmly partnered with SuSE as they were another company that did much of their work in Germany. Not to mention their common goal of linux to the desktop.

    Now to be critical of Novell. I have used SuSE both before, and after the Novell buyout. And to be honest I had much more confidence in their earlier systems stabilities. I manage quite a few linux boxen, and most are SuSE. (My boss is a Novell junkie to a fault.) My favorite boxes are inevitably the Debian-stable boxes. Yast is a foul stumbling block if you ask me. And I have had some trouble with features they say are ready for production. If the feature you want relys on a kernel module that is experimental then that feature, and/or your box will only be as stable as that module...No matter how much Novell insists otherwise. I will mention though that I have not found Xen to be an issue. It runs just as well as my patched vanilla kernels on other boxes.

  13. This is all no big deal by Sloppy · · Score: 2, Insightful

    This whole thing is all blown out of proportion, and is really no big deal at all. You have to keep in mind who Novell and Red Hat's customers are: companies that want vendor support. For whatever reason, one vendor has decided that it's profitable for them to support Xen, and one has decided that it's not.

    That's all this is about. Maybe a tiny piece of the issue has to do with the maturity of Xen, but it just as easily could have to do with how much staff each company has on hand, what areas their support staff has expertise in, whether or not some internal leader/guru has had the time to get around to even looking at Xen much less evaluating it, etc. Red Hat saying Xen isn't ready (i.e. "we can't or don't want to support Xen") isn't any different than me saying MacOS isn't ready (i.e. "I can't or don't want to support MacOS, probably because I don't happen to have a Mac conveniently sitting around right now.").

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  14. Incorrect Oracle stats by Finite9 · · Score: 2, Interesting

    "There is a similar case with Oracle. The default minimal install takes 800MB _RAM_ for a single instance, experienced DBAs claim you can go down as low as 300MB. MySQL is functional in 32MB, and shines in 64MB -- more memory is needed only if the dataset is big"

    Well, this is blatantly incorrect. a new instance of Oracle 9ir2 takes up as much memory as you allocate to it. If you choose "percentage of available physical memory" and you have 512MB and set it to 50% then the instance will take roughly 256MB. You can set the SGA manually to whatever you want, but performance wont be that great depending on usage!

    My dev. instance on XP Pro is 68Mb and I have several schemas that have datatfiles with 5GB in them - dataset size does not affect instance size, in Oracle at least, but I suppose that the poster may mean something else when referring to 'dataset'. I take it to mean 'the size of the data stored in the datafiles'. I know nothing about MySQL but would find it very strange if memory size was affected by dataset size...how much memory do you need then if the dataset is 1000TB?

    --
    "Everyone knows that vi vi vi is the number of the beast" -- Richard Stallman
    1. Re:Incorrect Oracle stats by Tim+C · · Score: 2, Interesting

      how much memory do you need then if the dataset is 1000TB?

      I suspect that the OP is caching at least some of his dataset in RAM. My current project uses Oracle 10g on a 4-way Solaris box with 32GB of RAM; we have that much RAM precisely so we can (attempt to) cache the entire dataset in RAM, thus reducing/eliminating disk I/O.

      On the other hand, if you don't care about caching huge amounts of data, you don't really need huge amounts of RAM.

      (Disclaimer: Damnit Jim, I'm a programmer, not a DBA!)

  15. Predictable by __aahlyu4518 · · Score: 2, Insightful

    If something will be the cause of linux never succeeding on the corporate desktop.. then it is this kind of 'infighting'. Sure they are competitors. But with the same base product (Linux distro + services). They have a partially shared goal. Without recognizing that, either a 3rd linux party will walk away with the clients, or linux will not be an option. Who wants a supplier that has nothing better to do than fighting it's own goals?

    1. Re:Predictable by TheRaven64 · · Score: 2, Insightful
      But with the same base product (Linux distro + services). They have a partially shared goal.

      I don't know what leads you to believe this. Novell's aim is to make as many people as possible run Novell's OS. Red Hat's aim is to make as many people as possible run Red Hat's OS. The fact that these have some common components is irrelevant. OS X uses bash, gcc and Apache; does this mean that Apple also has a partially shared goal with Red Hat and Novell? Microsoft Windows includes some 4.4BSD code, and so do Linux and OS X. Does this mean that Microsoft, Apple, Novell and Red Hat partially share a goal?

      Well, actually, they all do partially share a goal; owning the corporate desktop market. Why you think this would make them co-operative, however, is beyond me.

      --
      I am TheRaven on Soylent News
  16. It gets better.... by T-Ranger · · Score: 5, Insightful
    Initially a Windows software company, Novell turned to Linux-based software when it completed the acquisition of SUSE Linux in 2004.
    <nelson>Ha, hUh?</nelson> Novell was, if anything, initially a hardware company. OK, that Novell dosent count, Novell was initially network OS company (Netware), that supported primarily DOS! Ok, that doesnt count either: Novell was a focused on enterprise network services, with integrated directory services backed management. OK, no one knows what that means: Novell was focused on identity, asset, file and print, software and configuration services and management. Begining in the early 2000's, porting their products to both run on, and manage, linux systems, Novell entered the market full force when they aquired SUSE ..... But a Windows software company? WHAT IN THE FUCK?
  17. Re:Xen rocks? I don't think so. It just barely wor by IMightB · · Score: 4, Informative

    Never used SusE/Novell's version of Xen, but I CAN tell you that Fedora's is not compiled with PAE enabled, so you cannot address more than 4GB of RAM. It seems to me, like you are looking for a pretty serious VM performance/memory allocation. I am in the same situation, and have to recompile Xen from source with PAE enabled to get more the kind of memory allocation that I need.

    To save you some searching here's the make command

    make XEN_TARGET_X86_PAE=y install

    though for 64bit goodness you'll probably have to throw another flag in there.

  18. Mod Parent UP! by IMightB · · Score: 2, Interesting

    I agree completey, however, I'd just like to point out that Novell/SusE seems to be focusing more on the Desktop while RedHat is focusing more on the Server side. Personally, I feel that the server side is WAY more important, and gets "Linux" (in general) in the door and in the minds of the IT departments. The Desktop follows after that.