Hypervisor recommendation

[sshaikh]

Hi all,

I just bought a HP Microserver, which I understand many are using to play around with virtualisation. For those who don't know it's based on a 1.3Ghz dual-core Athlon II Neo N36L processor. It comes with a 250GB disk and 1GB ram. I will be adding my own second 2.5TB disk.

I wish to run multiple virtual machines on this hardware. My OS requirements are:

1) A up to date windows install that will run 24x7 and sees the second disk "natively" (and exclusively if necessary). That is, the 2.5TB disk shouldn't be virtual since it may be taken out to be read by other machines. The "OS" disk can be virtual if required.
2) A very lightweight Windows XP installation that will be turned on and off infrequently on demand. This may have its own virtual disk.
3) A lightweight Ubuntu installation that will run 24x7 that can have a virtual disk.
4-5) An optional two more Ubuntu installations as above.

I'm quite comfortable with using host based virtual machines (VirtualBox mainly), but since many have been using this particular server as a virtual lab I thought I should look to be a little more ambitious. My questions are as follows:

1) Based on the above use, is there a particular recommendation of HV technology? From what I read, both ESXi and Hyper-V R2 work relatively well on this hardware.
2) Probably an obvious one, but I presume I'll have to upgrade the RAM. Rather than going for the most I can afford (which is 8GB I guess) what's the minimum I can get away with?
3) Seeing as I have a "main" virtual machine, should I just stick to a Windows install and run the XP and Linux installs via VirtualBox etc? What's the difference between Hyper-V and "Hyper-V with 2008"?

 

[calvinj]

With only 1 gig of ram good luck doing much of anything with it. Worry about the upgrade of the ram first

 

[sshaikh]

Thanks - I kind of suspected that and will be upgrading! Any advice on the other questions?

 

[sybreeder]

I personally tested ESX and ESXi and as afaik esxi will be faster on your pc. apart from that is way easier to setup. Installation on usb flash took me about 10 min. Then i had to download vsphere and was good to go The machin was ready for VM after 30-40min. In case of Hyper-V everything will took much longer.
Is also little bit slower.
The Main difference between Hyper-V hypervisor and hyper-V with 2008 is that hypervisor works without Windows itself. It's similar to esx/esxi. Hyper-v can be also as role in windows 2008 R2 So you have to install whole os to work with VM. That can be a bottleneck and could slow down VM.
Minimum to run ESX/ESXi is 2GB but the more you have is better. However i have 3GB on my test platform with ESXi and it's workind fine.Even with 1core CPU.

 

[sshaikh]

Thanks sybreeder. Does ESXi allow me to allow a single VM direct access to a harddisk?

 

[defuseme2k]

I don't think you're going to get any of us virtualization nerds to tell you to buy any less memory than you can afford. That said, if 8 is what you can afford, then buy 8 GB. You should be able to run several VMs within that depending on the amount of resources you intend to give each.

You can use an RDM with local disks by hacking around a bit. It isn't supported with local storage out of the box. I know for your purposes the storage being virtualized could be annoying at a later date (it isn't a show stopper), but I don't recommend doing something unless it is supported. From my perch you're going to need a SAN target to give a VM raw access to a disk.

 

[haileris]

I use ESX for the most part at home but I have some experience of Hyper-V. I'm not sure which is the "quicker" - most of the comparisons that I remember seem to focus on server consolidation numbers - but anyway pretty sure that you won't notice much difference.

Hyper-V support RDM out of the box, there is no hacking around - you simply take the disk offline and map this into the VM. On the other hand, Ubuntu isnt supported, though it will work (http://mikehadlow.blogspot.com/2009/10/installing-ubuntu-on-hyper-v.html) for example.

My advice is to go with what you are used to. If you are a Windows person, choose Hyper-V. If you are a Nix person go with ESXi. AFAIK both choices will need a separate machine to administrate it, unless you pay for a Windows license or use technet.

 

[sshaikh]

Thanks guys. So my options are:

1) ESXi and try to get RDM working
2) Hyper-V Server and try to get Ubuntu working
3) Win2008 + Hyper-V, use the native host as my Win7 box (and so remove the need for any RDM) and still try to get Ubuntu working.

Thanks for all the help. I'd welcome more discussion, but for now I've got enough to make a start I think.

PS FYI I've bought a 4GB stick which I believe will take me up to 5GB.

 

[C7J0yc3]

If you're doing anything linux your best bet is to start with a hypervisor that isn't made by microsoft. Don't get me wrong, I love hyper-v, but introducing linux is a PITA on it.

If it were my money and my server I would purchase as much RAM as it would hold, and worry about disk later. You eat up RAM a lot faster then you eat up disk. I would then throw ESXi on there and provision my machines. Personally I have had no use for direct disk access and I actually prefer VHD / VMDKs as they are easier to manipulate when moving VMs around, and are also nice because they can be expanded on the fly. The only downside with ESXi is VMFS has a maximum file size of 2TB which means that you can't have a VMDK larger then that, but I have only needed that once, and I got around that by using a NFS target instead.

As far as having a disk that you are going to be swapping in and out as a storage disk I wouldn't recommend that. ESXi doesn't like losing its storage, and Hyper-V REALLY doesn't like it. If other machines need to access it you are better off attaching it permanently and then sharing it out with Samba.

 

[sshaikh]

Perhaps it's worth expanding on the drive requirement a bit more.

I won't be swapping it in and out frequently, and certainly not on a "hot swap" basis. The extra disc will be used to host files to share (media etc) as well as backups of other machines, so I just figured that it makes sense to keep those files "native" just in case I ever have to access them via another PC easily. The thought of wrapping these files in a virtual volume concerns me, but I'm guessing that's just inexperience/irrational.

But if I did move to a VMDK, the disc is already being used in this way (formatted with NTFS) with 800GB use, so what would be the best way converting it for use with ESXi?

 

[defuseme2k]

Perhaps it's worth expanding on the drive requirement a bit more.

I won't be swapping it in and out frequently, and certainly not on a "hot swap" basis. The extra disc will be used to host files to share (media etc) as well as backups of other machines, so I just figured that it makes sense to keep those files "native" just in case I ever have to access them via another PC easily. The thought of wrapping these files in a virtual volume concerns me, but I'm guessing that's just inexperience/irrational.

But if I did move to a VMDK, the disc is already being used in this way (formatted with NTFS) with 800GB use, so what would be the best way converting it for use with ESXi?

Warning: I'm a VMware nerd, so I'll keep it to that point of view. I'm both a fanboy and biased. Hey, at least I'm honest.

Yes it is probably your inexperience/comfort level with it that makes you apprehensive, but I don't think it is irrational. You did have a good justification for keeping it native if you were going to swap the disk on any sort-of regular basis. However, you just told us you're not going to be doing this much at all. What I get out of that, is your reasoning really revolves around if the OS fails or the virtual machine has issues you're worried about the recoverability of your files, in that sense, it is irrational. The .vmdk files are separate per virtual disk you add, and they are transportable and can be swapped out between virtual machines quite easily. Fear of recoverability is not a good reason in this case to make things more difficult, well, at least that is my 2 cents.

EDIT: To answer your question... there is no good way. Unfortuantely, you're going to have to move it elsewhere temporarily. The disk won't be formatted with a .vmdk exactly, it will be formatted with VMFS and it will host VMware related files; one of those will obviously be your intended .vmdk.

 

[sshaikh]

Thanks for the elaboration.

Essentially I'm just a commitment-phobe; getting all that data into a VMDK residing on a VMFS drive is a non-trivial task and I'll probably only want to do it once I know I'll be sticking with VMWare. Of course I can do that at a later date, after I'm more confident with ESXi.

When using VirtualBox etc, I consciously considered my VHDs as disposable. Logically I don't see why a VMDK would be any less resilient than an NTFS drive, but it still feels so; possibly due to my unfamiliarity with them.

Do VMWare users generally store "production data" files in VMDKs? Or do they do more complicated things like use SANs etc? Perhaps I'm thinking about all this the wrong way...

 

[defuseme2k]

Thanks for the elaboration.
Do VMWare users generally store "production data" files in VMDKs? Or do they do more complicated things like use SANs etc? Perhaps I'm thinking about all this the wrong way...

Yes. Very critical data is stored in vmdk's regularly. The "free" ESXi is the same code used in the enterprise version, in fact all you'd have to do to make those features available is enter a license key in the copy you've downloaded. So in turn, the .vmdk files you're dealing with are the same as fortune 500 companies, the DoD, and other large organizations use.

Usually LUNs cut from a SAN are formatted with VMFS. That also enables multiple ESXi boxes to see the VMFS volumes, making vmotion, ha, and ft possible.

 

[sshaikh]

Okay. I'm convinced. Thanks for all the help! I'll keep the thread updated on my progress.

 

[C7J0yc3]

VMDKs are just VMware's term for VHD, so yes production data gets stored in them, and those VHDs or VMDKs usually get stored on a SAN or some other form of centralized storage.

It is a little scary thinking that all your data is held in one single (basically) zip file, however the reality is that they are actually more reliable then physical hard drives. I have multiple physical disks fail every month (both customers and my own), however only once have I seen a VHD or VMDK get corrupted beyond the point of being able to salvage the data.

The nice thing about having VHDs or VMDKs is that they can be mounted directly on your physical machines. So if you have a VM that becomes non bootable because the OS or vms file becomes corrupt you can mount it directly on your windows or linux box and pull the data out by hand. They can also be swapped between guest oses easily so again if you have a data disk on a windows machine and windows decides to poop the bed and you need that data sooner then you would be able to fix the windows box, just shut down the windows box, and mount the disk to another machine (In ESXi no need to shut the destination machine down to add disk) and you are good to go.

 

[sshaikh]

Okay. So when I come around to creating the VMDK, what's the best way to transfer my existing data? Assuming I still have it on another disk I mean? The only way I can think of is over the network which will take hours. Is there an local environment in which I can see both the native disk and VMDK? Would that be by mounting the VMDK in my desktop machine like you pointed out I could do above, or is there an easier way?

 

[yankees9920]

It is a little scary thinking that all your data is held in one single (basically) zip file, however the reality is that they are actually more reliable then physical hard drives. I have multiple physical disks fail every month (both customers and my own), however only once have I seen a VHD or VMDK get corrupted beyond the point of being able to salvage the data.

I am nervous about storing my data in VMDK containers as well. Mainly because, while they may more reliable than hard drives, you are doubling the number of things that can cause you to lose your data. If either the hard drive or the VMDK gets corrupted, its lost. So I feel like having this second layer of abstraction just can't be as safe.

 

[defuseme2k]

I am nervous about storing my data in VMDK containers as well. Mainly because, while they may more reliable than hard drives, you are doubling the number of things that can cause you to lose your data. If either the hard drive or the VMDK gets corrupted, its lost. So I feel like having this second layer of abstraction just can't be as safe.

You know, I've been doing this for 5, or wait, hrm, 6 years now? I've never lost data because of vmdk issues. As far as the physical drive goes... do yourself a favor and buy a low end controller on the HCL that can do hardware raid. A simple mirror is a good idea.

As far as the OP's question goes... well, honestly you're probably better off storing the data elsewhere temporarily, building the VM (which includes wiping and formatting that disk with vmfs) and then doing a network copy for the first-run. You're going to migrate the data one way or the other... twice most likely.

 

[sshaikh]

Regarding software mirroring, is it possible to get ESXi to mirror VMDKs on your behalf? Sounds like a reasonable and easily implemented feature to have.

The other option would be to manually create two equally sized VMDKs (on different disks) and get the guest OS to mirror instead, but I don't see why this couldn't be done at the lower level. I also have RAID1 on the MB, but I have no idea how that would work in conjunction with ESXi (is it transparent to it?), so I'm just going to take that out of the equation.

FYI I do have a regular backup of my normal data, but it seems more appropriate to simply mirror the data (large media etc) on the server rather than go with a normal backup.

 

[defuseme2k]

Regarding software mirroring, is it possible to get ESXi to mirror VMDKs on your behalf? Sounds like a reasonable and easily implemented feature to have.

The other option would be to manually create two equally sized VMDKs (on different disks) and get the guest OS to mirror instead, but I don't see why this couldn't be done at the lower level. I also have RAID1 on the MB, but I have no idea how that would work in conjunction with ESXi (is it transparent to it?), so I'm just going to take that out of the equation.

FYI I do have a regular backup of my normal data, but it seems more appropriate to simply mirror the data (large media etc) on the server rather than go with a normal backup.

ESXi won't do any mirroring for you.

Your motherboard will do fake raid, not a true hardware based raid so it will not work. For that, you're going to need a controller on the HCL -- that is going to cost you some (someone else can chime in... I don't know the street prices).

A mirror is nice to have as it duplicates data and will allow it to survive a disk failure, but if you accidentally delete something.. the mirror isn't going to save you then, is it?

An OS level mirror across two virtual disks isn't that bad of an idea in this low end kind of a setup. I'd never recommend it in a production environment, because the redundancy had better be there hardware wise making that extra layer an unnecessary complication. In your case it probably would be OK.