by Duncan Epping
Duncan Epping · ·
Today I received the following error at a customer site when applying patch via the Update Manager:”Metadata for patch missing.” After a close inspection I noticed VirtualCenter wasn’t running on port 80 but on 81 for some reason. Opening up the ESX Firewall and restarting the VMware Update Manager service seems to fix this problem. The firewall was opened up as follows
esxcfg-firewall –openport 81,tcp,out,updatemanager
Duncan Epping · ·
For those who encountered the same weird networking problems as I did, I was just browsing through the Knowledge Base articles for the patches released yesterday and found out that they fixed the driver for the Intel quad-port nic. When using VST half of the packets were dropped, for more info on the problem check these blogs: 1 , 2.
Fixed ESX Server support for Intel Zoar NICs on a VLAN trunking configuration. A flaw existed between the ESX Server networking subsystem and the igb driver.
Duncan Epping · ·
I was just testing the new patches on a couple of servers when I noticed that when I pressed “remediate” the first patch(ESX350-200802403-BG) was installed without the ESX host going into maintenance mode. When the second patch(ESX350-200802409-BG) was installed the server went into maintenance mode. According to the VUM Documentation(vi3_vum_10_admin_guide.pdf) the server should always go into maintenance mode before installing the patches:
Update Manager puts ESX Server in maintenance mode before applying updates. Virtual machines cannot continue to run when an ESX Server is in maintenance mode. To ensure a consistent user experience, Update Manager migrates virtual machines to other ESX Server hosts before the server being remediated is put in maintenance mode.
I can imagine this happens because the system impact of the first patch is “No VM Shutdown & No Host Reboot” and for the second patch it is “VM Shutdown & Host Reboot”. Anyway, it would be a nice addition if one could choose to always enter maintenance mode before applying patches. It definitely gives me a more save feeling.
Duncan Epping · ·
On the Storage Nuts & Bolts Blog on the NetApp website there’s a sneakpreview on the Snapshot Manager for VI3 by NetApp. Here a couple of outtakes from the original article. Be sure to check the original article because there are also a couple of screenshots in there.
Although from the sound of it, it appears that SMVI is related to other SnapManager products like SnapManager for Exchange, SQL, SharePoint and Oracle, SnapManager for VI is not related to specific applications. SVMI rather serves as a medium to streamline the backup and restores of Virtual Machines and/or Datastores in a VMware environment. It interacts with VC or the ESX server and NetApp Storage devices and creates instantaneous backups and near-instantaneous restores of Virtual Machines and/or Datastores.
What can you backup and Restore?
You can backup at the Datastore level and Restore at the VM level or the Datastore level.Where can you restore a VM?
You can restore it on the original Datastore or a different Datastore. SVMI provides a listing of all existing datastore and you basically get to choose the one you want. Furthermore, you have the option to mount the backup and verify its contents.How does it backup?
SMVI temporarily leverages VMware’s snapshot which makes calls to the LGTO_sync (lgtosync.sys) driver part of the VMware tools which is responsible for flushing dirty buffers to disk for filesystem consistency and creates a Redo Log (Redo Log is a misnomer, it’s actually a bitmap) for storing disk changes. We keep the VMware snapshot around until we complete our Snapshot (NetApp) on the array side, which takes no more than a few seconds, at which point we delete the vmware snapshot, thereby merging the changes in the “redo log” with the original VMDK.
One thing that surprised me is that NetApp didn’t develop this cool add-on as a VirtualCenter Plugin… but within time this will probably happen.
Duncan Epping · ·
VMware just uploaded a whole bunch of patches for ESX 3.5:
ESX350-200802301-BG : Update to the bnx2 Driver
ESX350-200802303-SG : Security Update to the util-linux Package
ESX350-200802304-SG : Security Update to the Perl Package
ESX350-200802305-SG : Security Update to the openssl Package
ESX350-200802306-BG : VMware ESX Server 3.5, Patch ESX350-200802306-BG: Daylight Saving Time Update
ESX350-200802401-BG : Updates to vmware-hostd
ESX350-200802403-BG : Improved Statistics Collection for Support Scripts, Fix for Patch Issue Seen After Upgrading from ESX Server 2.5.x to 3.5.0
ESX350-200802404-BG : Resolves DMA Issues on LSI 1078 and 106XE HBAs
ESX350-200802405-BG : Update to MegaRAID SCSI Driver to Fix Dell PowerEdge 6650 Boot Issue
ESX350-200802406-SG : Updated aacraid Driver
ESX350-200802408-SG : Security Updates to the Python Package
ESX350-200802409-BG : Fix for Reset Issue with CD-ROM Controller
ESX350-200802410-BG : Unexpected Reboot of Virtual Machines Configured to Automatically Start or Stop
ESX350-200802411-BG : Enhanced Validation Checks, and Fixes for Storage VMotion and Lab Manager
ESX350-200802412-BG : Updates to the VMkernel to Fix Networking and Hardware Issues
ESX350-200802413-BG : Sunfire X4200 Host Hangs Because of HBA Timeouts Due to DMA Problems
ESX350-200802414-BG : Discrete Sensors Report Wrong Information to Monitors
ESX350-200802415-SG : Security Update to Samba Packages
And there’s also an update for 3i available:
ESXe350-200802401-I-BG : Update to the bnx2 Driver
Good luck with patching those hosts, I will be testing these patches later this day so if I encounter any problems you will be the first to know