De nieuwe builds kun je vanaf nu downloaden. In deze versie is detimebomb bug verholpen.
De nieuwe builds kun je vanaf nu downloaden. In deze versie is detimebomb bug verholpen.
VMware heeft een VMbook uitgegeven over Business Continuity and Disaster Recovery:
This VMware® VMbook focuses on business continuity and disaster recovery (BCDR) and is intended to guide the reader through the step-by-step process to set-up a multisite VMware Infrastructure that is capable of supporting BCDR services for designated virtual machines at time of test or during an actual event that necessitated the declaration of a disaster, resulting in the activation of services in a designated BCDR site.
Download de pdf hier: practical_guide_bcdr_vmb.pdf
Je krijgt nu de beschikbare updates te zien. Yes de U2 timebomb issue staat er tussen.
Klik Install Updates en de update wordt gedownload.
Voor dat je de update kan gaan installeren moet je even aanmelden als root.
en de update word geïnstalleerd.
In deze post lees je hoe ik de update op een testserver heb geïnstalleerd. Ik heb de patch naar de ESX host gekopieerd en vervolgens geïnstalleerd. Dit kun je natuurlijk op verschillende manieren doen. Via een NFS share, IIS repository, FTP of zelfs een VMFS lun. Maar het princiepe blijft hetzelfde:
Het volgende verschijnt nu op je scherm:
[root@ESX35SRV1 ESX350-200806812-BG]# esxupdate update
INFO: No repository URL specified, going with file:///var/tmp/ESX350-200806812-BG
INFO: Preparing to install [‘ESX350-200806812-BG’]…
INFO: Downloading VMware-esx-vmx-3.5.0-110181.i386.rpm…
INFO: Downloading VMware-hostd-esx-3.5.0-110181.i386.rpm…
INFO: Checking disk space and running test transaction…
INFO: Running yum install <2 packages>…
INFO: | Gathering header information file(s) from server(s)
INFO: | Server: Bundle ESX350-200806812-BG
INFO: | Finding updated packages
INFO: | Downloading needed headers
INFO: | VMware-esx-vmx-0-3.5.0-11 100% |=========================| 3.0 kB 00:00
INFO: | VMware-hostd-esx-0-3.5.0- 100% |=========================| 8.8 kB 00:00
INFO: | Resolving dependencies
INFO: | Dependencies resolved
INFO: | I will do the following:
INFO: | [update: VMware-esx-vmx 3.5.0-110181.i386]
INFO: | [update: VMware-hostd-esx 3.5.0-110181.i386]
INFO: | Downloading Packages
INFO: | Getting VMware-esx-vmx-3.5.0-110181.i386.rpm
INFO: | Getting VMware-hostd-esx-3.5.0-110181.i386.rpm
INFO: | Running test transaction:
INFO: | Test transaction complete, Success!
INFO: | VMware-hostd-esx 100 % done 1/4
INFO: | INFO: No change to default locale settings detected.
INFO: | INFO: Setting up vmUser(uid 12/gid 20)
INFO: | INFO: vmUser(uid 12/gid 20) setup
INFO: | INFO: Regenerating /etc/ld.so.cache
INFO: | INFO: vmware-hostd has been upgraded, it needs to be manually
INFO: | INFO: restarted in order for the upgrade to take effect…
INFO: | INFO: type /etc/init.d/mgmt-vmware restart
INFO: | VMware-esx-vmx 100 % done 2/4
INFO: | Completing update for VMware-esx-vmx – 3/4
INFO: | Completing update for VMware-hostd-esx – 4/4
INFO: | Updated: VMware-esx-vmx 3.5.0-110181.i386 VMware-hostd-esx 3.5.0-110181.i386
INFO: | Transaction(s) Complete
INFO: Shutting down hostd…
INFO: Running esxcfg-boot to regenerate initrds…
INFO: Restarting hostd…
INFO: — TOTALS: 2 packages installed, 0 pending or failed, 0 removed, 0 excluded —
INFO: Install of [‘ESX350-200806812-BG’] succeeded.
Daarna kun je de VM’s weer gewoon starten.
De patch is beschikbaar. Ik zal later vandaag een post maken over het installeren van de patch.
An issue has been uncovered with ESX/ESXi 3.5 Update 2 that causes the product license to expire on August 12, 2008. Follow the steps below to correct this issue:
- Read the following Knowledge Base articles first:
- Download and apply the patch according to the product(s) you have:
VMware ESXi 3.5 Update 2 Patch | VMware ESX 3.5 Update 2 Patch
VMware heeft inmiddels een bericht de deur uit gedaan:
Dear VMware Customers,
Please find the latest update about the product expiration issue. From this point on, we’ll provide an update every two hours.
An issue has been discovered by many VMware customers and partners with ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or VMotion successfully. This problem began to occur on August 12, 2008 for customers that had upgraded to ESX 3.5 Update 2. The problem is caused by a build timeout that was mistakenly left enabled for the release build.
– VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2.
– Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patches applied: ESX350-200806201-UG
– No other VMware products are affected.
*What has been done?:*
– Product and Web teams pulled the ESX 3.5 Update 2 bits from the download pages last night so no more customers will be able to download the broken build.
– VMware Engineering teams have isolated the cause of the problem and are working around the clock to deliver updated builds and patches for impacted customers.
– A Knowledgebase article has been published (http://kb.vmware.com/kb/1006716), but traffic to the knowledgebase is causing time outs. A new static page has been published at http://www.vmware.com/support/esx35u2_supportalert.html that customers and partners will be able to view.
– The phone system has been updated to advise customers of the problem
– Vmware partners have been notified of the issue.
1) Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.
2) Set the host time to a date prior to August 12, 2008. This workaround has a number of very serious side affects that could impact product environments. Any Virtual Machines that sync time with the ESX host and serve time sensitive applications would be broken. These include, but are not limited to database servers, mail servers, & domain administration systems.
VMware to notify customers who have downloaded this version and provide an update every two hours.
VMware Engineering has isolated the root cause and is working to produce an express patch for impacted customers today. The target timeframe is 6pm, August 12, 2008 PST.
* What would this express patch do?
More information will be provided in subsequent communication updates.
* Will VMware still reissue the upgrade media and patch bundles in the timeframe that has been communicated? \\ \\ \\ Yes. We still plan to reissue upgrade media by 6pm, August 13 PST (instead of noon, August 13 PST) and all update patch bundles later in the week. We will provide an ETA for the update patch bundles subsequently. NOTE: the “patch bundles” referred to here are for the patches listed above under “Affected Products” and the other bundles released at GA. They are not the same as the express patch which is targeted for 6pm, August 12, 2008 PST as stated above.
* Why does VMware plan to reissue the upgrade media before the patch bundles? That is a wrong priority call! \\ \\ \\ This is not a matter of priority. Since we can get done building and testing the upgrade media before the patch bundles, we want to make that available to customers first instead of reissuing all the binaries later in the week.
* Can VMware issue a patch that opens the licensing backdoor in the next hour as a critical measure?
There is no licensing backdoor in our code.
* Does this issue affect VC 2.5 Update 2?
* What is VMware doing to make sure that the problem won’t happen again?
We are making improvements on all fronts. The product team had endeavored to deliver a release with support customers deem important. But we fell short and we are deeply sorry about all the disruption and inconveniences we have caused. We have identified where the holes are and they will be addressed to restore customers’ confidence.
The VMware ESX Product Team
Tim Jacobs heeft op zijn blog een super artikel geschreven over Full backups of virtual machines and Windows VSS.
One of the new features that is appearing in backup products that take backups of an entire virtual machine, as opposed to using an agent inside the guest operating system, is the ability to cooperate with Windows VSS (Volume Snapshot Service) inside the guest. For example, the recently released version of VMWare’s Consolidated Backup 1.5, now supports VSS quiescing for Windows 2003, Windows Vista, Windows 2008; vizioncore’s vRanger Pro backup utility has been supporting VSS for Windows 2003 for some versions already.
Several opinions exist on whether this is in fact a useful feature or not; for example, not so long ago the developers of esXpress talked about not including VSS quiescing into their product at that time because it adds additional complexity and does not offer any significant benefits in their opinion (see here). This discussion is still alive as you can see for example here, and the big question is indeed: can you rely on live backups of database virtual machines?
Lees de rest van het artikel hier: http://timjacobs.blogspot.com/2008/07/full-backups-of-virtual-machines-and.html
Starting this morning, we could not power on nor VMotion any of our Virtual Machines. The VI Client threw the error “A general system error occurred: Internal Error”.
Further digging lead us to messages like this one in /var/log/vmware/hostd.log, and the log file for any virtual machine we tried to power on or VMotion:
Aug 12 10:40:10.792: vmx| http://msg.License.product.expired This product has expired.
Aug 12 10:40:10.792: vmx| Be sure that your host machine’s date and time are set correctly.
Aug 12 10:40:10.792: vmx| There is a more recent version available at the VMware Web site: http://www.vmware.com/info?id=4.
The work-around: turn off NTP (if you’re using it), and then manually set the date of all ESX 3.5u2 hosts back to 10th of August. This can be done either through the VI Client (Host -> Configuration -> Time Configuration) or by typing date -s “08/10/2008” at the Service Console command line on the ESX hosts.
As soon as the date was reset to the 10th – problem solved.
Note that running VMs were operating fine, this only seems to affect initial VM power-on (including from suspended state) and VMotion.
Reactie van een medewerker van VMware:
“Dear VMware customers,
We are actively working on rootcausing the problem. Once we know the appropriate action to take here, we’ll provide an update.
Apologies for any inconvenience.
The ESX Product Team”
Op het VMUG forum staat nu ook een topic: http://www.vmug.nl/modules.php?name=Forums&file=viewtopic&t=2953
Daarin schrijft JCvanDoorn het volgende:
Hier is een kort lijstje met wat recommendations van een van mijn collega’s:
1. Set DRS to manual
2. Do not VMotion
3. Do not power off or suspend VM
4. If you have some important VMs you need to turn on again
a. Create a quarantine host – a standalone host without any VMs
b. Set time on this host back
c. Verify, that your VM will not synchronize its time with that host
d. Cold migrate VM to the quarantine host
e. Power VM on, log into it and set check the time setting. If necessary set the time manually
You could also think about temporarily disconnecting the VM to power on from the Virtual Switch. This way you are certain that the VM will not be able to communicate with a DC while it’s out of time-synch. This allows you to set the time manually before connecting it back to the Virtual Switch.
Inmiddels heeft VMware zelf ook een melding op hun supportsite geplaatst: http://www.vmware.com/support/
En het topic in de VMware communities is nog steeds groeiende: http://communities.vmware.com/message/1020565