What I learned today – HA Split Brain, USB “Support”, Fix Broken OVF Exports…

Describes HA Split Brain, USB "Support" and how to fix broken OVF exports.

Today I learned 3 new things – and I wasn’t even supposed to be working! 

HA Split Brain (Split Brian?):

Split Brain is an 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 your VMotion switch, undesired consequences can occur. 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% sure why, or if in fact if the underlying value has changed – or that VMware has merely corrected its own documentation. You see it's 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 a trivial matter if you take the neccessary network redundancy 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 it's a bug. No, it's not a bug. It’s just there, but you can’t out with it. NICE! The best we can say at the moment is that it has been put there for some future technology which may or equally may not become available. However, I personally feel some USB-over-IP device is the best way to go.

Fix Broken OVF Exports:

This has 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 the OVF Template using the vCenter4. To check that 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”

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>

Finally, I delete the .MF file. This file carries out a checksum calculation on the .OVF file to stop direct edits to the OVF file from corrupting it. By removing the file it stops the checksum process.

 

This was first published in July 2009

Dig deeper on VMware Resources

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close