This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Anything come close to esx for xen?

To: "Thomas Goirand" <thomas@xxxxxxxxxx>, <lists@xxxxxxxxxxxx>
Subject: Re: [Xen-users] Anything come close to esx for xen?
From: "Nick Couchman" <Nick.Couchman@xxxxxxxxx>
Date: Wed, 25 Feb 2009 08:53:34 -0700
Cc: xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 25 Feb 2009 07:54:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
I think there are a couple of parts to this and that saying "keeping things old school" is over-simplifying the situation.  Yes, Xen needs to keep a CLI in the product.  CLI isn't just old school - there are plenty of people still using CLI, and they aren't just the people who have been working on computers for 30 or 40 years.  CLIs offer flexibility, they're easier to automate, they help when trying to debug problems.  There are many, many advantages to having a CLI.  However, if the argument is that we should keep things to CLI only, I don't think that's what anyone is saying.
I can also see the benefits of having an easy-to-use GUI interface for Xen - a "turn-key" solution, if you like.  VMware definitely has an advantage in that you install their product (ESX or ESXi), configure a few things like your network interfaces and datastores (both relatively simple tasks in ESX/ESXi), and start creating VMs.  ESX manages to maintain a decent amount of flexibility, especially when it comes to defining networks.  However, there are areas where VMware lacks flexibility, especially areas like storage management, hardware support, etc.
There's also a disagreement over how to offer/implement that sort of solution.  People like Mike (users vs. developers) don't really care how the solution is offered or implemented, they just want a disc that you can pop into a drive, run through a fairly automated install process and come out with a working Xen host on the other end.  That's a great goal - it makes Xen easier to use for people who either don't have the time or expertise to fiddle with all of the intricacies of getting Xen and Linux running from scratch.  However, there are others who want to make sure that the "turn-key" solution is implemented properly - these are the people who are arguing that the Xen package itself should not include the GUI.  Xen is the hypervisor, the GUI ought to be a separate package that interacts with the hypervisor, not something that gets bundled up into the hypervisor.  (As a side note, ESX/ESXi is built in a very similar fashion - there's the VMKernel, which is the actual hypervisor, and there are a couple of dozen packages added to give the web functionality, volume management, clustering, client interface, etc.  However, to Mike's point, he doesn't have to know all this - he just throws the disc in the drive and it works.  Of course, you can only manage it from Windows...)
Anyway, that's just my two bits on the matter - I don't think that what people on both sides of the issue are saying is incompatible or unattainable, it just isn't ready right now.  Too bad...

>>> Thomas Goirand <thomas@xxxxxxxxxx> 2009/02/24 23:45 >>>
lists@xxxxxxxxxxxx wrote:
> You want to keep things old school, [...] keep it cli

I wont continue to talk about this topic again because it seems Mike and
he doesn't want people to reply to his posts, but I still want to say
that NO, this is not what I think.


This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

Xen-users mailing list
<Prev in Thread] Current Thread [Next in Thread>