daemon.child

In the early days of the Internet data links were slow and lots of traffic was based on single character transactions. For example, the telnet protocol sends a single byte at a time as you type. This isn't great use of the available bandwidth as the overhead of delivery is very large. An IP header is (a minimum of) 20 bytes and a TCP header is another 20 bytes. That means that to deliver one byte of data, cost a minimum of 40 bytes. That's 40:1. Not good. To make this worse, each packet will require an ACK packet to come back from the other end of the connection.

ESXi is great. Which is fortunate as it is also the way that VMware is going in the long run. There will be no service console before too much longer (although I can't get a fixed date on when out of my insiders within VMware). When you need to drop away from the vSphere client and interact with the vmkernel through commands and scripts, it can be a bit limiting. The VMware management Appliance (vMA) is very handy in most cases. But there are some times when you really do need to run commands on the ESXi server itself. Without a service console how do you do this? Read on.

This article describes how to install ESX4i onto a USB 'Pen' drive using a Mac. I found this article which is very useful if you are unfortunate enough to have a PC.

Today I moved my standard vSwitch networking over to a distributed switch. It went well. Ok. I lie, it didn't go well at all. To be fair the main part of the work had gone very well. I've migrated all my virtual machines over successfully to the new port group. I've even migrated my ESXi management network vmkernel port over too. All was looking great until I renamed the dvUplinks.

FreeBSD 8.0 doesn't natively support an iSCSI target server. This was a bit of a surprise when I discovered this fact, but I was sure that the ports database would include something that I could use. This technote shows how to set up the target server I found and have working. I'm running VM's on it from my ESXi servers and performance seems pretty good. (Especially considering that the FreeBSD installation in question is also a virtual machine, but that is another story...)

The iSCSI target server that I'm using is the istgt daemon. To compile and install this is simplicity itself.

Today, I had the dubious pleasure of attending a client site to tidy up, change passwords and deny access for a guy who has just been fired. They had clearly decided a few weeks ago that he was going to be fired if he didn't improve. I've worked alongside him before and I can see why he got the boot. He meant well, but the spark wasn't there. They knew he'd be angry and obviously thought that he would become the fabled 'disgruntled employee' of many a security white-paper.

From vSphere forwards, VMware has included fully working and supported access to SATA based hardware. This includes using that hardware for allowing a virtual machine to see those drives directly through a RDM (Raw Device Mapping). This means that it is possible to share cheap and plentiful local storage directly with virtual machines. Why is this of interest to the corporate environment? Well, perhaps it isn't really that useful in the 'real' world. But it's bloody handy at home!

Storage multi-pathing is an important technology that's been built into VMware for fibre channel SANs for some time. It's handled automatically for FC (and hardware iSCSI actually): just put more than one HBA into your server and off you go. This is not the case for software iSCSI however. There is only one software iSCSI initiator inside the vmkernel, so you can't do multi-pathing, right? Hmm... read on.

When you convert a physical server into a virtual machine using VMware converter, it is only possible to create full sized 'thick' disks. Ok, so you can resize the volume from the original server during the conversion, but the .vmdk file that you end up with is stored in thick format. This might not be what you want. It usually isn't. Most people want sparse disks now that thin provisioned disks are fully supported in vSphere. (The current version of converter is 4.1.1).

Most days, I really, really love working with VMware. When the system is working sweetly and the VMs are all happily migrating about in their little swarms, then I'm happy too. But when the dark clouds of instability start to mass on the horizon, it can be a hard day at the office. This was nothing to do with VMware and everything to do with bad design.