Virtuozity

Parallels announced the upcoming availability of Parallels Server for Mac Bare Metal Edition, a type-1 hypervisor which doesn’t need any host operating system to run. So the “for Mac” in the title just means that this specific version of the product supports Apple Xserve hardware, and thus allows customers to run Mac OS X Server virtual machines. Parallels offers a version of this hypervisor that supports other enterprise class x64 hardware since October 2009 but of course the Apple EULA prohibits to run Mac OS X Server guest operating systems on it.

Both versions share the same engine and so offer the same capabilities:

• Up to 12 vCPUs / 64GB vRAM / 2TB vHDDs / 16 vNICs / 8 USB 2.0 ports per VM
• Support for Intel VT-x, VT-d, FlexPriority and EPT
• Support for AMD-V and RVI
• Support for 32/64bit guest OSes (including all flavors of Windows, Red Hat, SUSE, Debian and Ubuntu Linux, FreeBSD)
• Templates and snapshots
• VM full and incremental backups (Windows and Linux guests only)
• VM live migration
• CPU resource limits, prioritization and disk I/O priority
• Cold V2V migration between Parallels Servers Bare Metal hosts (VM to VM, or even VM-to-container / container-to-VM) and hot V2V migration (only for containers)
• Cold P2V migration from physical servers to virtual machines or containers
• Local management console and a CLI for most tasks within a single host
• Parallels Virtual Automation (formerly Parallels Infrastructure Manager) for enterprise management

Today Parallels may be the only company providing a viable virtualization platform for server and client consolidation on Xserve hardware. This will be interesting for classic server consolidation, but it will be a breakthrough if you are thinking about the possibilities regarding OS X based VDI environments. I am definitely looking forward to this release!

VMware announced the end of life (EOL) for its Consolidated Backup (VCB) framework. The company states that the next version of vSphere, due later this year, will not support VCB and will solely rely on the new vStorage APIs for Data Protection (VADP) introduced with vSphere 4.0.

VCB binaries will be still available and supported on VI 3.x and vSphere 4.0 according to the support policy, but they will not be included in the new platform. Most partners with a strong focus on backup/restore already support VADP. VMware promises that even more vendors will offer VADP-based solutions in time for the next vSphere release.

VMware has implemented some new features in the VMFS file system in vSphere 4 and these updates bring some good news for you: In the past you had to consider the block size very carefully when formatting a VMFS volume, because in VI3 configuration and log files were stored within the VMFS for the first time. This meant that every file allocated at least the chosen block size, no matter how large or small it really was. VMFS in vSphere 4 introduced the ability to store smaller files in so-called 64KB "sub-blocks" to save disk space.

So choosing a small block size will not give you an advantage anymore, it will only limit you in the future in case you want to grow your VMFS! Yes, that's another difference, you are not limited to extents in vSphere 4, now you able to really grow your VMFS, which makes it even more flexible. Unfortunately the VMFS wizard will still ask you to format your volume with 1MB block size by default. I would recommend to choose the largest available block size here to be as flexible as possible, because changing it later is not possible.

By the way, it is definitely false information that the chosen block size will impact your storage performance, but: Another highly acclaimed feature by VMware is thin provisioning. As you already figured out yourself, you should be pretty careful using it in your production environment, although there are cases in which it will be very useful. In my opinion thin provisioning also makes sense with larger VMFS block sizes, because increasing the VMDK file in tiny 1MB chunks doesn't look like best practice to me.

Link: http://nss.cs.ubc.ca/remus/

Remus is an open source project which provides fault tolerance for virtual machines (VMs) running on the Xen hypervisor. The actual release 0.9 works with tip of the xen-unstable repository, supports paravirtualization and hardware VMs in various 32- and 64-bit configurations for Windows and Linux.

Remus provides transparent, comprehensive high availability to ordinary virtual machines running on the Xen virtual machine monitor. It does this by maintaining a completely up-to-date copy of a running VM on a backup server, which automatically activates if the primary server fails. Key features:

• The backup VM is an exact copy of the primary VM. When failure happens, it continues running on the backup host as if failure had never occurred.
• The backup is completely up-to-date. Even active TCP sessions are maintained without interruption.
• Protection is transparent. Existing guests can be protected without modifying them in any way.

I am looking forward to the day Remus will be announced stable and hopefully integrated into XenServer sooner than later!

The standard for Service Console (SC) RAM in ESX 3.5 server is 272MB. This minimum is fine for the standard server that does not have installed any other software. But you might have proprietary hardware agents, backup solutions or other software installed, and you might run into serious trouble you are unaware of, if do not expand the SC memory (e.g. HA agent errors). 512MB should be enough for most scenarios, but if you don't mind you can go for the maximum of 800MB. You have to configure the RAM size in the ESX configuration file

/etc/vmware/esx.conf

Just search for /boot/memSize = "272" and enter your value. After that you will have to deal with GRUB and the init process, because the settings are boot-relevant. ESX server has proprietary aliases for that, the command is esxcfg-boot. You have to run it twice: First time to regenerate the GRUB configuration files, the second time to recreate the initrd file with the new settings. You might want to use this short shell script, that does it all for you:

sed -i 's/memSize = "[0-9][0-9][0-9]"/memSize = "800"/' /etc/vmware/esx.conf
esxcfg-boot -g
esxcfg-boot -b

Because you have to reboot the host to take effect, so you should plan this for your next ESX patch day.