Hi.
What would be the best solution for virtualization? Xen or VMware server to run zimbra as virtual machine?
Thanks.
Printable View
Hi.
What would be the best solution for virtualization? Xen or VMware server to run zimbra as virtual machine?
Thanks.
Hands down VMWare. With Xen you cannot access the optical drives without going through a whole bunch of bull$it. I have been running VMWare server (free) for about 6 months now and it's very stable if run on Linux. I would suggest CentOS as a host system.Quote:
Originally Posted by norixam
-Tim
Why not XEN? You will have MUCH MUCH more performance when you use a paravirtualised Linux. VMWare Server will introduce paravirtualisation in Version 2, but this version is still Beta and will be released later this year.
So if you know a bit Linux, then I strongly advise to use XEN . My favorite distribution is Ubuntu and I recommend this to you (Zimbra is tested and supported under Ubuntu 6.06 (but not CentOS) and this distribution runs smoothly under XEN).
Regards,
Tobias
Virtual Iron 8)
You don't have to use CentOS as the guest OS by any means. I have several FreeBSD, Windows, and SuSE installations running on top of VmWare. Go ahead and check out how you have to install from CD if that is the way you want to install a guest OS in Xen. It's convoluted and annoying. I am as much a command line guy as anyone but I simply don't want to mess with that crap when installing the OS. With VMWare, I can just pop in a CD and go. Xen is nice for network installs but until they fix the CD problem I'm staying with VMWare.Quote:
Originally Posted by tobru
-Tim
I use VMWare quite a bit and I find the clock drift problem, which is much more significant with Linux 2.6 guests than with Linux 2.4 or Windows, irritating for things like email that might be time sensitive. When a VM or the host is busy I've seen VMs clocks be wrong by tens of minutes (when the load drops they gravitate back towards the right time).Quote:
Originally Posted by norixam
Personally, I'd go for Xen over VMware for the above reason if nothing else. I use UML for my current Zimbra VM, and have found the performance hit for I/O operations and CPU intensive user-mode code to be noticeably lower than that imposed by VMWare - I'm guessing the performance of Zimbra under Xen will be no worse than UML and probably better as Xen doesn't impose quite as high a performance hit on system calls (I keep with UML rather than moving towards Xen simply because it is more than good enough for my uses and I am already familiar with its ins-and-outs).
One big point to the contrary though: if you already run VMWare on your host machine(s) then use VMWare instead of using two virtualisation solutions.
Simple solution from the RedHat support pages but will work with almost any OS:Quote:
Originally Posted by dspillett
-TimQuote:
When running a guest operating system under VMware it is important to follow all of VMware's instructions regarding installation and configuration of the desired operating system as a VMware guest, including installing the VMware Tools package.
Time synchronization problems are a common VMware guest configuration issue which occur when VMware Tools have not been installed on the guest and configured according to VMware's instructions. VMware virtualizes the timer/clock functions seen by the guest OS, so even ntpd does not function correctly. This is not a problem with the operating system, it is a by-product of running the OS under VMware.
To correct the time drift problem seen in the guest OS, install the VMware Tools package in the guest OS and enable time synchronization for the VMware guest session the OS runs under. VMware Tools packages for all current versions of Red Hat Enterprise Linux are provided with the VMware software product, and specific instructions for installing VMware Tools for each type of guest OS is provided in VMware's built-in help menu system as well as in other VMware product documentation.
The following is a brief summary of the steps to enable VMware host-to-guest time synchronization:
* Install VMwareTools in the guest OS, following VMware's instructions for the target OS.
* Enable VMware time synchronization in the guest. There are two simple ways to accomplish this:
1. Run the vmware-toolbox GUI applet from within an X session on the guest, and turn on the checkbox in the Options tab titled "Time sychronization between the virtual machine and the host operating system".
2. On the HOST machine, locate the <session name>.vmx VMware session configuration file for the guest OS in question, and add a line which reads:
Note that if a tools.syncTime line already exists in the .vmx file, it must be set to "TRUE" to enable the time synchronization.Code:tools.syncTime = "TRUE"
After making the changes described in either method, shut down the guest Red Hat Enterprise Linux operating system, then close and restart the VMware guest session.
Running the ntpd daemon should not be required in the guest with VMware's time synchronization enabled, though using ntpd on the host system would be recommended to keep the host (and guests') time synchronized to a reliable time source.
Please refer to VMware's support channels for further VMware documentation and support information, such as the VMware website.
Oh I tried all that, but still sometimes the clock would drift by a noticeable amount of minutes before being drawn back in. http://www.vmware.com/pdf/vmware_timekeeping.pdf is a good explanation of why there is sometimes such issues. Of course, I've not always been working on the bets of hardware which will magnify any such problem. And for a lot of people, a little clock drift over a short period simply isn't a big issue (but I'm picky).Quote:
Originally Posted by windependence
If you want to use VMWare with kernel 2.6 based hosts and do experience the time problem on your setup, then you can always compile your own kernel with options (like the length of a jiffy) tweaked towards the 2.4 defaults. Whatever you do don't run NTP or similar in VMWare guests - it's interaction with VMWare's clock management tricks (it tries to use the interrupt insertion/skipping method even without the VMWare tools being installed in the guest OS) will make matters worse, not better.
But for my uses (the Zimbra server I run is for personal use at the moment, and if I convince the office to move over we'll run probably it on a physical box), user-mode-linux is simply the least-hassle-for-a-lazy-person solution. I've nothing significant against VMWare (it's a good product, I've used paid-for versions of it on-and-off for a good few years and the current free products are exceptional value for money!) - I just prefer other tools for this particular job.
Hello.
I would like to thank all for your suggestions ... but seen by each of us has a different point of view. Normal this happens, we all have different tastes. Initially when I go to VMware server, the ease of implementation. After studying want to do over Xen, particularly because I incentive of free software.
I am considering running VMware on top of Debian 4.0 and Ubuntu 6.06?
Thanks all ..
If you are not particularly technically experienced, you might find VMWare the better way to go initially, as it probably requires less technical know-how to get started. Not that UML (and presumably Xen) requires much more jiggery pokery. In the end, if you are running a small system for testing it won't make much difference.Quote:
Originally Posted by norixam
I've not run VMWare on a Linux host, so I can't help you with installation hints. I'm told the installation instructions on VMWare's site a fairly robust though. What you use as the host operating system will make no difference to the VMs you run under VMWare so use what-ever you prefer as long as VMWare support it.Quote:
Originally Posted by norixam
For the VM that will be running Zimbra, I doubt there is much difference between Ubuntu/Dapper and Debian/Etch. You might want to prefer Ubuntu 6.06 as it is listed as supported for both NE and FOSS installs, and Ubuntu 6.06 (server installs - desktops installs are not supported as long) is listed as officially supported (i.e. will receive timely security updates) for 18 months longer than Debian/Etch (see Debian - Wikipedia, the free encyclopedia and Ubuntu (Linux distribution) - Wikipedia, the free encyclopedia).