Vallard Land

from the release notes:

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5/html/Release_Notes/installation.html

You just specify:
%packages
@Everything
-@Conflicts

This isn’t supported by VMware obviously or you’d be looking at their documentation.  However, this is an extremely useful way of provisioning ESXi on to servers.  For starters, suppose you have a server running some accounting software during the day and you want to test that server by running virtual machines on it (VMs will be mounted from a NAS or something somewhere else).

One of the options I’ve seen from IBM is that you can buy their cool thumb drive which will set you back perhaps a few $100 ?  I don’t know the price.  The other option is to say “Thumb drives are so 2001.  Get with the times man!”  And then pay nothing by just network booting the image.  Network booting is the only way to have real control of your data center and make it agile.   Otherwise you’re stuck with the same scenario of the fool with the crash cart which is what you’re trying to avoid, right?  If you’re using a crash cart to configure your servers, then you probably don’t have a cloud, nor an agile data center.

Ok grasshopper, this is how it is done:
1. Download the image from VMware. In my example, I’m getting the ESXi 4.0 image specialized for IBM hardware so that I can get the remote console to work. (That’s what happens if you don’t get the right one).

2. Mount the image and copy the contents of the file to some place. I copied all the files to /install/esxi4/x86_64/

3.  cd /install/esxi4/x86_64/;  tar zxvf image.tgz

4.  This should create the directory usr/lib/vmware/installer.  Now extract this image:

• cd usr/lib/vmware/installer
• bunzip2 VMware-VMvisor-big-4.0.0-208167-x86_64.dd.bz2

5.  Take a look at the sectors to see which one we need to get:

• fdisk -lu VMware-VMvisor-big*dd

# fdisk -lu VMware-VMvisor-big-4.0.0-208167-x86_64.dd
last_lba(): I don't know how to handle files with mode 81a4
You must set cylinders.
You can do this from the extra functions menu.

Disk VMware-VMvisor-big-4.0.0-208167-x86_64.dd: 0 MB, 0 bytes
64 heads, 32 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes

 Device Boot      Start         End      Blocks   Id  System
VMware-VMvisor-big-4.0.0-208167-x86_64.dd1            8192     1843199      917504    5  Extended
VMware-VMvisor-big-4.0.0-208167-x86_64.dd4   *          32        8191        4080    4  FAT16 <32M
VMware-VMvisor-big-4.0.0-208167-x86_64.dd5            8224      520191      255984    6  FAT16
VMware-VMvisor-big-4.0.0-208167-x86_64.dd6          520224     1032191      255984    6  FAT16
VMware-VMvisor-big-4.0.0-208167-x86_64.dd7         1032224     1257471      112624   fc  VMware VMKCORE
VMware-VMvisor-big-4.0.0-208167-x86_64.dd8         1257504     1843199      292848    6  FAT16

Partition table entries are not in disk order

The goods are inside *dd5.  We see that the sector starts at 8224.  Lets mount this partition.

6.  mkdir /install/stage

7.  mount VMware-VMvisor*dd /install/stage -o loop,offset=4210668

• offset is 4210668 because 512 * 8224 !

8.  ls /install/stage

boot.cfg    cim.vgz      mod.tgz  pkgdb.tgz  vmkboot.gz
cimstg.tgz  license.tgz  oem.tgz  sys.vgz    vmk.gz

9.  Lets modify these images so that we can SSH into it.  SSH is just so useful!  This is done by making our own mod.tgz.  If you extract the one you see there then you’ll find that its empty!  So lets put something in it.

1. mkdir -p tmpdir/etc/vmware/init/init.d/
2. Put a file called ’47.enable-ssh’ that has the following:

#!/bin/sh
sed -ie 's/#ssh/ssh/' /etc/inetd.conf #ssh is too nice not to have
return ${SUCCESS}

3.  copy an /etc/shadow into tmpdir/etc/shadow that has root’s password so you can ssh in with your password.

4.  Go back to your tmpdir root and tar it up:  tar czvf mod.tgz etc/

5.  Copy this mod.tgz over the empty one.

Nice work!  Now you’re ready to rock.  You’ll need to set up dhcp and tftp to deliver the goods.  Here’s what we do:

1. Put all those files (boot.cfg, cimstg,tgz, you new mod.tgz file, mboot.c32, oem.tgz, pkgdb.tgz….. all those) into /tftpboot/esxi4/
2. Make a PXE file for the node.  Mine looks like this:

#netboot esxi4
DEFAULT xCAT
LABEL xCAT
 KERNEL /esxi4//mboot.c32
 APPEND /esxi4/vmkboot.gz ---\
/esxi4/vmk.gz --- \
/esxi4/sys.vgz --- \
/esxi4/cim.vgz --- \
/esxi4/oem.tgz --- \
/esxi4/license.tgz --- \
/esxi4/mod.tgz --- \
/esxi4/cimstg.tgz

Provided you have tftpboot and dhcp setup correctly, you can now just pxeboot these files and watch as your node comes up in a stateless ESXi hypervisor.  Now I know what you’re saying:  What about keeping track of virtual machines on the server?  If it reboots, it comes up fresh and I don’t know what virtual machines should be there?  This is true.  But I’m not going into that right now.  You’ll have to pay extra for that

Anyway this may all seem like a lot of work to get up and running, but the convenience is awesome.  All this information was gleaned from the xCAT source code that we wrote.  xCAT does this for you automatically.  Or for a more painless setup, you could use the Sumavisor to do it.  Anyway, hope this helps and gets you thinking!

Ah, one last tidbit:

If you are on the console and want to log in directly to ESXi4, just do Alt+F1 and type: unsupported, then the prompt will come up (telling you its unsupported) and then you can just enter the root password you had from your /etc/shadow that you copied in and have access.

As I’ve been running Sumavi, my new company for the last 2 months I’ve been thinking a lot of what types of activities I can do to make it successful for the near term and the long run.  One of the themes that has constantly come to my mind is the “Use what you sell” message.

This is something I first thought of while working at IBM.  I was developing a product called CSM.  I thought it was pretty good, but none of the sales engineers liked it.  They all used xCAT instead.  Its not like they didn’t try it.  Some did.  They tried CSM and they went right back to xCAT.  They would think:  “Why pay for something I don’t like when I can get this software kit that I love for free?”

In addition to this manufacturing started using xCAT to test all their clusters and then even the nascent On-Demand center standardized on xCAT as well.  None used CSM.

After going out into the field and working with customers I saw pretty clearly why CSM wasn’t meeting the needs of our customers.  But at the same time, it was difficult to describe the frustration to my old development team.  They would ask for bullet pointed lists of things that were wrong with it.  I would stay up late at night trying to pinpoint all of my issues, but it just didn’t resonate.  It could be my lack of communication skills or that I just couldn’t describe it.  I found that some people got very defensive.

In a matter of time CSM became end of life and the team was disbanded.  Now some of those people are part of the xCAT development team.  Its been great to continue to work with them.  I’m now outside of the blue curtain, but I’m still an open source contributor to the xCAT project.

I find myself thinking all the time if I’m drinking too much of my own Kool-Aid.

I think the best thing that we could have done back then was send developers out to the customers that use it, or at the very least work with internal customers.  Have a rotation where a developer needs to join support to at least get a first glimpse of how customers use the code.  This is something that I think made xCAT successful.  We would make changes or get feedback right away from our customers.  I hope to do this with Sumavi.  In fact, we’ll have our first beta customer in a week from tomorrow where we’ll get a chance to see what we’re made of.

But you don’t even have to go that far.  Consider for example Lotus Notes at IBM.  They are doing a great job of using what they sell.  However, they’re more ramming it down other people’s throats.  Think of all the nick names I heard for it from IBM employees.  IBM has a gold mine of enterprise users that are smart and know good software when they see it.  All IBM needs to do is send an email to all the employees that reads:

“We’re conducting a manditory brief survey.  Click <yes> if you like Lotus Notes.  Click <here> if you think its ok, and Click <here> if you really dislike it. You may also enter comments below if you like:”

Simple.  Then all the managers just have to make sure the employees fill it out.  Its easy to do, IBM made me do it every year with my BCGs. (Only in this case, they need to make sure its anonymous)

Then, depending on the results, you either give the Senior VP of Lotus Notes a raise, or you fire him.  My guess is that they will probably end up firing them.  The point is, you have all these internal ways and attitudes in your corporation and you need to look at the truth and stop kidding yourself or your project will be dead.

My prediction is that if Notes doesn’t shape up, it won’t be around much longer.  Nobody I have ever talked to about it likes it.  I don’t think it would be too hard to make work either.

Here’s what I would suggest:

- Make it work natively on my iPhone.  (Maybe this is just IBM’s implementation and it works fine everywhere else, don’t know)

- Give me a non-java client, or let it integrate seemlessly with Apple Mail

- Why on earth is there a program called “Zap-Notes” that will allow you to kill the notes processes without restarting your computer?  This is embarresing.

- Start limiting the function of it and focus on core things.  Start innovating.  Stop playing catch up.

Anyway, hopefully others will have the same painful advice for me on the Sumavisor that we’re creating at Sumavi.  But you know what we’re going to do?  We’re not going to ignore it.  We’re going to take it, and do our best to make at least 75% happy.  (Why 75%?  Because some people will never be happy, especially people in IT. (But we’re still going to try!))