Following on from this weeks series – today I learned 3 new things – and I wasn’t even supposed to be working! After getting up at 4.00am to take my partner and her daughter to the airport, I thought I’d take it easy by going back to bed, and then later catching up with some telly on me Sky+ box… But even just by doing as little as that I learned a couple of tidbits – mainly by keeping a watchful eye on my email and the forums.

HA Split Brain (Split Brian?):

Split brain is HA situation where an ESX host becomes “orphaned” from the rest of the cluster because its primary service console network has failed. As you might know the COS network is used in the process of checking if an ESX host has suffered an untimely demise. If you fail to protect the COS network by giving vSwitch0 two NICs or by adding a 2nd COS network to say your VMotion switch, underdesired consequences can occour. Anyway, the time for detecting split brain used to be 15 seconds, for some reason this has changed to 12 seconds. I’m not 100% why, or if in fact the underlying value has changed – or that VMware has merely corrected its own documentation. You see its possible to get split brain in Vi3.5 happening if the network goes down for more than 12 seconds, but comes back up on the 13th, 14th or 15th second. I guess I will have to do some research on this one. Of course, the duration can be changed – and split brain is trival matter if you take the neccessary network redundency steps…

USB “Support”:

This is an odd one. You can in a VM on ESX4 add a USB Controller. The VM must be hardware level 7 for this to be the problem. The trouble is – it doesn’t do anything. And no amount of adding or loading drivers at the COS will allow you to plug a USB device into an ESX host, and have it appear in the VM. You might ask if it doesn’t work does that mean its bug. No, its not a bug. It’s just there, but you can’t owt with it. NICE! The best we can say at the moment is that its been put there for some future technology which may or may equally may not become available. As ever I personally feel some USB-over-IP device is the best way to go.

Fix Broken OVF Exports:

This happened to me twice now. I power down a perfectly functioning virtual appliance (in my case the UDA 2.0 which is currently in beta) and export it to be OVF Template using the vCenter4. To check the export has been successful I re-import it only to get to 100% complete, but end with an unpleasant error message “Failed to deploy OVF package: The remote server returned an error: (500) Internal Server error”

The last time this happened to me I twittered about it – finally some helpful guy who follows me on twitter helped me fixed the problem. [I only wish I could remember his name because he deserves the credit for this fix!] It’s not clear precisely why it happens, but appears that occasionally the Export function of vCenter4 creates an OVF file that misreports the size of the virtual disk. A quick edit to the OVF file is all that is needed. So below is my “bad” OVF File:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!– Generated by VMware VirtualCenter Server, User: Administrator, UTC time: 2009-07-21T13:53:10.761609Z –>

<Envelope vmw:buildId=”build-162856″ xmlns=”http://schemas.dmtf.org/ovf/envelope/1″ xmlns:cim=”http://schemas.dmtf.org/wbem/wscim/1/common” xmlns:ovf=”http://schemas.dmtf.org/ovf/envelope/1″ xmlns:rasd=”http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData” xmlns:vmw=”http://www.vmware.com/schema/ovf” xmlns:vssd=”http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>

<References>
<File ovf:href=”uda20-beta-build5-disk1.vmdk” ovf:id=”file1″ ovf:size=”207287808″ />
</References>

<DiskSection>
<Info>Virtual disk information</Info>
<Disk ovf:capacity=”1” ovf:capacityAllocationUnits=”byte * 2^30” ovf:diskId=”vmdisk1″ ovf:fileRef=”file1″ ovf:format=”http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized” />
</DiskSection>

The bad part is highlighted in bold. To correct this I found out the actual size of the -flat.vmdk by using ls at the Service Console:

I then modify the .OVF file accordingly:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!– Generated by VMware VirtualCenter Server, User: Administrator, UTC time: 2009-07-21T13:53:10.761609Z –>

<Envelope vmw:buildId=”build-162856″ xmlns=”http://schemas.dmtf.org/ovf/envelope/1″ xmlns:cim=”http://schemas.dmtf.org/wbem/wscim/1/common” xmlns:ovf=”http://schemas.dmtf.org/ovf/envelope/1″ xmlns:rasd=”http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData” xmlns:vmw=”http://www.vmware.com/schema/ovf” xmlns:vssd=”http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>

<References>

<File ovf:href=”uda20-beta-build5-disk1.vmdk” ovf:id=”file1″ ovf:size=”207287808″ />

</References>

<DiskSection>

<Info>Virtual disk information</Info>

<Disk ovf:capacity=”2040109056” ovf:capacityAllocationUnits=”byte” ovf:diskId=”vmdisk1″ ovf:fileRef=”file1″ ovf:format=”http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized” />
</DiskSection>

This entry was posted on Tuesday, July 21st, 2009 at 4:25 pm and is filed under Other. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.