Tip

What I learned today – HA Split Brain, USB “Support”, 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

    Requires Free Membership to View

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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.