the birdhouse in my soul

The vCenter Server Appliance in vSphere6 can be deployed as "tiny", "small", "medium", and "large". The deployment wizard gives info about the vCPU and vRAM consequences of this choice, and about the total disk size of the appliance. But as there's 11 (eleven!) disks attached to the VCSA appliance, it's worth looking into which disks get a different size. Tiny Small Medium Max hosts 10 100 400 Max VMs 100 1000 4000 vCPU 2 4 8 vRAM 8 16 24 Disk size 120 150 300 disk0 / and /boot 12 12 12 disk1 /tmp/mount 1,3 1,3 1,3 disk2 swap 25 25 50 disk3 /storage/core 25 50 50 disk4 /storage/log 10 10 25 disk5 /storage/db 10 10 25 disk6 /storage/dblog 5 5 10 disk7 /storage/seat 10 25 50 disk8 /storage/netdump 1 1 10 disk9 /storage/autodeploy 10 10 25 disk10 /storage/invsvc 5 10 25 N.B. I currently don't have the config data for "large". This table can help if your environment is growing slightly or wildly beyond th...

Imagine wanting to access a VM, but you don't know the IP address, and you don't have a GUI client for your vSphere environment? The most basic way of getting the IP address of a VM from the vSphere hypervisor level, is logging in to the ESXi Shell (could be local or SSH), and finding your VM number in the VM list: # vim-cmd vmsvc/getallvms In my example, my VM has number 42. Then type # vim-cmd vmsvc/get.summary 42 | grep ipAddress       ipAddress = "10.11.12.13",  Et voila! NB this requires running VMware tools in your guest OS, evidently.

While playing around with the bios.bootDeviceClasses parameter (as shown in this example ), we found out that a device not specified in allow: would still be used if all "allow:"ed devices are unusable (no CD connected, no PXE server found, etc.) a device specified in deny: would still be used if all other devices are unusable. So contrary to what the documentation suggests, "allow:" will just move certain devices to the front of the boot device list, and "deny:" moves those devices to the end of the list. Hope this can help other people trying to make sense of setting boot order in a VM to achieve a specific behavior. In our case: get a VM to reliably boot from CD for automated deployment using the SDK.

I won't blog about the whole vhv.allow="true" procedure here, that's been covered elsewhere. But what does nested virtualization change in a VM ? Well, the CPU features that are exposed change: A regular 64-bit Linux VM sees # grep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx hypervisor lahf_lm ida arat A 64-bit VM with nested virtualization enabled sees # grep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx hy...

My home lab got upgraded with a new gigabit switch recently. Main improvement I wanted over the old Linksys SLM2024 I had: Cisco Discovery Protocol. Based on that requirement and the budget, I selected the Cisco SG300-28 Small Business managed switch. The web interface is clearly improved compared to the SLM2024, and CDP is a real treat. Both vSphere ESXi and the cdpr utility under Linux decode the CDP information nicely. CDP is a great help to find errors in patch cable arrangement !

A fresh install of RHEL6 contains several vSphere-ready components: the standard kernel package contains kernel modules for the optimized VMware virtual hardware (network, storage, and memory balloon driver). vmxnet3 vmw_pvscsi vmware_balloon and just like in earlier RHEL releases, there's drivers for the VMware graphics card and the mouse driver: xorg-x11-drv-vmware xorg-x11-drv-vmmouse Especially the built-in network and storage drivers will make life easier for RHEL admins in vSphere environments. That's great news ofcourse, but I'd like to stress that this is not equivalent to a full VMware Tools install, which would include extras such as shutdown/reboot/freeze/resume scripts, IP address display in the vSphere client, etc.

(An update of an older post: now with vSphere 4.1 info. Further updated in 2011 with vSphere 5 info.) Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes ESX 4.1 - BIOS Release Date: 10/13/2009 - Address 0xEA2E0 - Size 89376 bytes ESX 5 - BIOS Release Date: 01/07/2011 - Address 0xE72C0 - Size 101696 bytes

I've been into virtualization for a long, long time, so I was familiar with the USB-over-IP concept. It has always been the preferred way to bring USB into a virtual machine, because it doesn't limit the flexibility of virtualization: live migration (vMotion), failover (HA), fault tolerance, ... can all handle USB-over-IP. But I was still surprised to find a cheap USB-over-IP device in a local computer store: the Belkin Network USB Hub , NUH for short. 100 USD list price, became EUR 90 retail price here in Belgium. Not the greatest deal around, but no reason to feel grumpy. Now let's see what this baby can do: the test setup consists of the Belkin NUH and two clients: a Windows Vista 32-bit laptop connected over WiFI and a Windows 2008 R2 64-bit VM on VMware vSphere connected over wired GigE. Then I gathered a diverse set of USB devices: USB memory sticks, USB hard drives, a USB smartcard reader, and a USB CD/DVD writer. The NUH gets a DHCP address by default (can be change...

My original home lab, three years old now, included two PC's running virtualization software, with Intel core 2 quad CPU's and 8 GB RAM each. While browsing for a replacement, I found Didier's Shuttle SX58J3 review . I researched some alternatives, but decided to go for the SX58J3 as well, fitted with 12 GB RAM and i7-970 CPUs, hexacores with hyperthreading. shallow: depth is critical in my telco rack. reduced height: I might get 4 shuttles in the same space as 2 minitowers earlier. They're actually slightly wider, but not by much. 12 GB per server is 50% more than the old lab (16 GB is supported but slower) the Intel core i7-970 CPU gives 100% more MHz than the old Q6600. They are much more expensive, truth be told. But being Westmere generation, they support vSphere4.1 features like DirectPath I/O and Fault Tolerance. I can re-use the PCIe dual gigabit adapters I had in the old lab. One real problem so far: in BIOS v100, I couldn't change any setting without rende...

VMware pre-compiles the VMware tools for selected OS kernels. The stock RHEL kernels are included, but not the intermediate updates. If you can live with that, you can simply add the VMware tools YUM repository: # cd /etc/yum.repos.d/ # wget http://bert.debruijn.be/linux-stuff/vmwaretools.repo and download the VMware RPM signing key # cd /etc/pki/rpm-gpg # wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub Then install the tools packages: # yum install vmware-tools-nox or # yum install vmware-tools vCenter will report the tools version as "Unmanaged" rather than "OK", but you have heartbeat (so HA and alarms can detect guest OS crashes), balloon driver, etc.

I recently added a dedicated storage box to my lab environment. After a week these are my first impressions: Pro: Small. I needed a shallow rack-mountable device, and this one is perfect, only about 50cm deep. Fast. I knew that a NAS device like this wouldn't be the speed king of the storage world, but I'm pleasantly surprised. Open software. It runs Linux, you get SSH access to your device, and you can add packages if you want. Evidently, I added tools like dstat to keep an eye on things. Compatibility. Used it from Windows Vista, VMware vSphere, and Linux (CentOS and others). No problems at all. Cheap. I could have gone for an EMC Symmetrix instead, but decided against it :-) Con: Fragile. Just a bit. The SATA ports of the disk drives slide directly in sata plugs inside the device. I hope I won't have to re-plug drives all too often. Not all operations happen online. QNAP advertises RAID1 to RAID5 migration, and it does that, by using one of the mirrored drives and the n...

Red Hat and related distro's (like CentOS) use 1000 timer interrupts per second, per CPU core or thread (this is called the "HZ value" inside the kernel). Because this causes a lot of extra work in case of virtualization, and caused (past tense since RHEL 5.4!) problems with timekeeping, the " divider " kernel parameter has been introduced. For example, by booting with "divider=10", the kernel uses 100 timer interrupts instead of 1000, and "divider=25" means 40 timer interrupts per second. I did a little test today to see what difference that makes when running CentOS5.4 on vSphere. Tests were done with the current 2.6.18-164.11.1.el5 x86_64 kernel in a single vCPU VM. These are the results from my test environment: standard settings: HZ=1000: 60 MHz cycles used when idle. divider=2: HZ=500: 36 MHz cycles used when idle. divider=5: HZ=200: 25 MHz cycles used when idle. divider=10: HZ=100: 20 MHz cycles used when idle. divider=25: HZ=40: a...