Christopher J. Umina

This has been fixed as of update 1.

If you’ve tried to install the vSphere client on Windows 7, you’ve undoubtedly come across errors like the following:

Error parsing the server "192.168.2.2" "clients.xml" file.
Login will continue, contact your system administrator.

and

The type initializer for 'VirtualInfrastructure.Utils.HttpWebRequestProxy' threw an exception.

Although Windows 7 is fully released now, nobody seems to feel like supporting it. Though, I guess Microsoft did kindof rush it out the door… Anyway, there’s a nice PowerShell script out there that allows you to fix this stupidity. After browsing the VMWare community, I came across this URL:

http://www.tinyint.com/index.php/2009/09/04/vsphere-client-on-windows-7/

I followed the instructions and now everything is working the way it should be. Maybe VMWare could just… do this for you ?

A strikingly similar situation as with the Sun I posted about earlier. The installation actually was quite easy after having completed the Sun configuration.

1. Install LDAPUX (available from HP’s site somewhere, just google for ‘download ldapux’).
2. On slapd: Make sure the ‘profile’ OU is accessible by anybody. It doesn’t store sensitive data, but should be able to be read by the HP-UX system in question.
3. Follow the instructions on: this guy’s blog
4. Make sure you do this stuffs too!
   1. Make sure you select option 1 when it asks which type of directory server you’re trying to connect to.
   2. Make sure your ‘credentialLevel’ is set to ‘proxy’ if you want to use a proxy user.

Well worth mentioning:

There’s a way more updated version of the iSCSI Initiator on the developer’s public FTP site.

ftp://ftp.cs.huji.ac.il/users/danny/freebsd/

With this version I’m now seeing acceptable IO (around 65MB/s reads/writes) after setting tags=256 in iscsi.conf.

All credits to the developer.

Because I’m in the US, I have fairly bad connectivity to that site. I’ve mirrored it here:

http://uminac.com/mirror/ftp.cs.huji.ac.il/users/danny/freebsd/

After plenty of hours of trying to figure out why it was that Sun’s native LDAP client wouldn’t talk to my OpenLDAP server I decided to call support. I had been through just about every Google result I could read and still got nowhere.

It turns out that when you use the native client you’re required to make some security concessions. The LDAP client’s config files exist only to tell it what server to initially try to connect to. The server it initially connects to MUST allow non-TLS queries to get some session information from the directory. The session information has to be in a specific form, and contain specific information.

I don’t have time for a proper tutorial right now, but I will post the document Sun sent to me.

Using Sun’s native LDAP client or OpenLDAP’s client to query an OpenLDAP server on Solaris 10

Please see the update to this post

As A Target (Server)

The only available iSCSI target software in FreeBSD is the /net/iscsi-target port. This is the iSCSI target from OpenBSD and is absolutely not suitable for production use (or even most non-production uses).

Problems I’ve come across:

• Does not support CHAP.
• Will not allow multiple connections to the same target (LUN). This is useful in the case of VMWare ESX/ESXi.
• Cannot rehash configuration file. If you add/remove a target you must restart the daemon completely, ending all current connections.

As An Initiator (Client)

The iSCSI initiator in FreeBSD 7.2 (currently) suffers from many issues. These issues prevent it from being suitable for production use. There is, however, a newer version of the iscsi_initiator kernel module shipping in 8.0-BETA1 and the -current branch (HEAD). By nature these versions of the FreeBSD operating system are not suitable for production use.

Problems I’ve come across in FreeBSD 7.2:

• No official documentation. While it is a simple configuration, you have to find procedures strewn about the web.
• Poor performance without tags tweak. I achieved no better than 2MB/s transfer rate without setting tags = 256 in iscsi.conf.
• No rc scripts. Devices must be attached after boot by admin or cron.
• System lockups under loads. Copying files to the iSCSI array via gigabit has repeatedly locked the system up. To test I copied the files from a local disk to the array and had the same result.

Problems I’ve come across in FreeBSD 8.0-BETA2:

• It includes an updated version, but it just flat out doesn’t work. When attaching the target with iscontrol -n targetname the iscontrol process hangs forever and cannot be killed with a -9.
• Still no rc scripts of any kind.

Comments are welcome.