Other VM software for Linux

[Red Squirrel]

I ran VMware server 1.0 for a while, but then it stopped working on newer releases of Linux so I was forced to use 2.0 which is very unstable and has no real client. the VI client can sorta be used but lot of features don't work.

So I switched to virtualbox. VB is ok, but it's meant more as a desktop VM app then a server VM app. So I need to start the VMs manually at system startup, the files are scattered everywhere, and they are not portable. (can't grab a vm file from one machine and drop it on another and run it).

I'm wondering what is an alternative program that is more meant for servers. Basically I want something like ESXi, but that runs on the host OS. My server does other tasks on the host so a hypervisor is not what I need.

I heard of KVM, is it any good? What else is out there? Virtualbox is working ok, but just want to look at what other options exist, and something that is more "background" but has a decent remote client interface.

 

[mundhra]

have you tried searching for virtualbox cli stuff (one, two, three)? as far as moving images maybe here or here?

i only use vb as a desktop app, so i don't really have any experience with the needs you have. the only other virtualization platform i know of is xen.

 

[mundhra]

dupe.

 

[Red Squirrel]

Hmm xen sounds interesting. Is it a hypervisor in the sense it's it's own OS, or can it run on an existing OS? TBH I'm actually debating on if I just want to virtualize my whole environment... while I rather not, it's not out of the question either.

 

[Nothinman]

What's wrong with VMware Server 2.x? I admit I liked the 1.x client better than the Tomcat crap, but it works fine for me.

Xen is a hypervisor with a Linux kernel dom0 to manage it.
KVM is a kernel module for using the VT extensions and a patched version of qemu to actually run the guests.

 

[Red Squirrel]

Vmware 2.0 is way too unstable. Not so much the back end, but the front end. The webGUI crashes ALL THE TIME, have to keep refreshing and stuff to get anything done. Half the time you can't even log in without null pointer exception errors, and have to restart the whole service (which restarts the VMs). It's a POS interface. If you go on VMware forums you'll see I'm not the only one with this issue so it's nothing to do with my setup, it's a rather standard setup...

It's too bad since I've always liked the free vmware products and like to stick with VMware as it is the industry standard, and we use ESX at work.

 

[Nothinman]

You can restart the Tomcat server without touching the VMs with the /etc/init.d/vmware-mgmt script. Although I rarely even use the web interface for anything besides creating new VMs.

 

[child of wonder]

Originally posted by: Nothinman
You can restart the Tomcat server without touching the VMs with the /etc/init.d/vmware-mgmt script. Although I rarely even use the web interface for anything besides creating new VMs.

This.

My VMWare 2.0 server runs Debian AMD64 as the host OS (which only serves a Samba share) and a few virtual machines including my virtual Endian router/firewall. I rarely use the VMware web interface at all, though it can be a pain when I do.

Still, the VMs run great and I love having my DC, mail server, web server, and router all virtual.

 

[Crusty]

VMware Server 2.0 is far better than 1.0. Are you sure you're not underpowering the box thus making the web interface sluggish? I've been running 2.0 on a 2x Dual Core Opteron server with 4Gb of ram that runs 4 VM's and I have no problem with the web interface.

I have noticed that if the box is under really heavy load the web interface can be flakey, but I've never had to restart the whole vmware-server because of it.

 

[Brazen]

Virtualbox guests are portable. I moved workstation guests between machines with no problem. More specifically, I copied off the Virtualbox guest, wiped and reloaded the host, and moved the VirtualBox files back. There could be something with keeping the guest on the same host hardware, but since the next version of VirtualBox is supposed to include live migration, portability shouldn't be a problem.

I use VirtualBox as a server, too. I use vboxtools to automatically start my guest servers in the background on system startup. The biggest issue is the open source version of VirtualBox does not include an RDP server and there is no other way to connect to background guests. Not even the VirtualBox gui can connect to guests already running in the background. This wouldn't normally be an issue if you set up your guests with the gui and configure remote management tools, but if a guest is ever unreachable remotely, you won't be able to look it without doing a hard poweroff and bringing it up in the gui. I prefer to stick with the open source version, but the rdp server is one reason you might want to use the closed source version of VirtualBox.

After working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

 

[crontab]

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

 

[Red Squirrel]

Originally posted by: Brazen
Virtualbox guests are portable. I moved workstation guests between machines with no problem. More specifically, I copied off the Virtualbox guest, wiped and reloaded the host, and moved the VirtualBox files back. There could be something with keeping the guest on the same host hardware, but since the next version of VirtualBox is supposed to include live migration, portability shouldn't be a problem.

I use VirtualBox as a server, too. I use vboxtools to automatically start my guest servers in the background on system startup. The biggest issue is the open source version of VirtualBox does not include an RDP server and there is no other way to connect to background guests. Not even the VirtualBox gui can connect to guests already running in the background. This wouldn't normally be an issue if you set up your guests with the gui and configure remote management tools, but if a guest is ever unreachable remotely, you won't be able to look it without doing a hard poweroff and bringing it up in the gui. I prefer to stick with the open source version, but the rdp server is one reason you might want to use the closed source version of VirtualBox.

After working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

Hmm interesting. What version are you using? Mine is a little behind so maybe it will be better if I just upgrade. I like the live migration thing... I was planning to code that myself at some point later but if it will be built in... sweet! My version would of been to pause the vm then unpause it on another host.

 

[Brazen]

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

 

[Brazen]

Originally posted by: RedSquirrel

Originally posted by: Brazen
Virtualbox guests are portable. I moved workstation guests between machines with no problem. More specifically, I copied off the Virtualbox guest, wiped and reloaded the host, and moved the VirtualBox files back. There could be something with keeping the guest on the same host hardware, but since the next version of VirtualBox is supposed to include live migration, portability shouldn't be a problem.

I use VirtualBox as a server, too. I use vboxtools to automatically start my guest servers in the background on system startup. The biggest issue is the open source version of VirtualBox does not include an RDP server and there is no other way to connect to background guests. Not even the VirtualBox gui can connect to guests already running in the background. This wouldn't normally be an issue if you set up your guests with the gui and configure remote management tools, but if a guest is ever unreachable remotely, you won't be able to look it without doing a hard poweroff and bringing it up in the gui. I prefer to stick with the open source version, but the rdp server is one reason you might want to use the closed source version of VirtualBox.

After working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

Hmm interesting. What version are you using? Mine is a little behind so maybe it will be better if I just upgrade. I like the live migration thing... I was planning to code that myself at some point later but if it will be built in... sweet! My version would of been to pause the vm then unpause it on another host.

I am using the latest version. I am actually using the closed source version, even on my desktop, just because VirtualBox's Ubuntu repo only includes the closed source version. I don't use any closed source features on my desktop, but if I wanted the open source version I'd have to go with the out-of-date version already in Ubuntu or compile the latest version myself.

It was quite a while ago when I reloaded my machine though. I was probably still on version 1.x or maybe 2.x at the time.

 

[child of wonder]

Originally posted by: Brazen

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

Still, using Virtualbox as an enterprise class solution over ESX is ballsy.

I'd be curious to hear what performance problems you had with ESX.

 

[Red Squirrel]

Originally posted by: child of wonder

Originally posted by: Brazen

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

Still, using Virtualbox as an enterprise class solution over ESX is ballsy.

I'd be curious to hear what performance problems you had with ESX.

Actually we use ESX at work and while in general it performs well, it's biggest issue is snap shots. Seems they cause tons of disk activity and eventually fill the whole drive. We had a crash on our data server when someone made an innocent snap shot not realizing it would be this much an issue. Any snap shot over a day old will start to cause issues, and it takes ages to delete them too.

The licensing is also a real nightmare. Why do they make it so complicated? Just getting the licensing working correctly was a project on it's own (couple weeks).

Though other then that I'm surprised to hear of performance issues with it as it's been pretty good for us. We also have killer IBM machines running it.

 

[Nothinman]

Any snap shot over a day old will start to cause issues, and it takes ages to delete them too.

Deleting them can take some time because it's got to merge the changes back into the original vmdk, however keeping them around a while shouldn't cause any real issues. We've had months old snapshots that we've deleted without issue.

 

[Red Squirrel]

Originally posted by: Nothinman

Any snap shot over a day old will start to cause issues, and it takes ages to delete them too.

Deleting them can take some time because it's got to merge the changes back into the original vmdk, however keeping them around a while shouldn't cause any real issues. We've had months old snapshots that we've deleted without issue.

Yeah that's what I find odd tbh. I've used vmware at home quite a lot and never ran into any of the issues we had at work. At home I don't thin provision, ever though. At work the san is too small to thick provision, so think that's why we pay for it...

 

[child of wonder]

Originally posted by: RedSquirrel

Originally posted by: Nothinman

Any snap shot over a day old will start to cause issues, and it takes ages to delete them too.

Deleting them can take some time because it's got to merge the changes back into the original vmdk, however keeping them around a while shouldn't cause any real issues. We've had months old snapshots that we've deleted without issue.

Yeah that's what I find odd tbh. I've used vmware at home quite a lot and never ran into any of the issues we had at work. At home I don't thin provision, ever though. At work the san is too small to thick provision, so think that's why we pay for it...

Snapshots should be deleted as soon as you no longer need them since they grow rapidly. They're similar to a SQL transaction log in that respect. They also degrade LUN performance.

Keeping snapshots on top of snapshots is especially bad since, not only can the snapshots fill the LUN, you also need to have enough space to delete the snapshots.

Now, if your VMFS volume has tons of space to spare, your SAN I/O and latency aren't anywhere near their peak, and there are very few VMs sharing the same LUN, then keeping a snapshot around for a long period of time isn't as bad.

 

[crontab]

Originally posted by: Brazen
Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

How large is your environment? Number of hosts and guests.

 

[Brazen]

Originally posted by: child of wonder

Originally posted by: Brazen

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

Still, using Virtualbox as an enterprise class solution over ESX is ballsy.

I'd be curious to hear what performance problems you had with ESX.

Performance wasn't a "problem" per se. But in my testing, I found vbox had better performance.

 

[Brazen]

Originally posted by: crontab

Originally posted by: Brazen
Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

How large is your environment? Number of hosts and guests.

5 hosts, about 25 guests

 

[child of wonder]

Originally posted by: Brazen

Originally posted by: child of wonder

Originally posted by: Brazen

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

Still, using Virtualbox as an enterprise class solution over ESX is ballsy.

I'd be curious to hear what performance problems you had with ESX.

Performance wasn't a "problem" per se. But in my testing, I found vbox had better performance.

On what kind of hardware? Disk? FC? SAS? SATA?

I'm not doubting what you're saying, just as a VMware guy I'm curious to hear experiences others have had with it and other virtualization products.

 

[Brazen]

Originally posted by: child of wonder

Originally posted by: Brazen

Originally posted by: child of wonder

Originally posted by: Brazen

Originally posted by: crontab

Originally posted by: BrazenAfter working with most mainstream virtualization packages for a considerable amount of time, VMWare Server 1, VMWare Server 2, VMWare ESX, XEN, KVM, qemu... I find that it's the best on the desktop, and it's the least problematic for a server.

What issues did you find when using ESX in the server environment that led you to pick virtualbox over it.

Worse performance, image-level backups are a problem (vcb backups fail constantly), no linux client, OS support lags behind vbox, and cost.

Still, using Virtualbox as an enterprise class solution over ESX is ballsy.

I'd be curious to hear what performance problems you had with ESX.

Performance wasn't a "problem" per se. But in my testing, I found vbox had better performance.

On what kind of hardware? Disk? FC? SAS? SATA?

I'm not doubting what you're saying, just as a VMware guy I'm curious to hear experiences others have had with it and other virtualization products.

3 servers are dual Xeons with 8 gigs of RAM, 2 servers are dual 4-core Xeons with 32gigs of RAM. All attached to EMC fibre channel SAN with 1gbps fibre channel backbone