VMware Workstation 6.0.0 45731 With Keygen Serial Key Keygen
Sanora Ngueyn
It is now possible to run VMware ESX 3.0.1 servers inside a VMware Workstation6.0 (Build 45731) if you have specific processors in your system. These processors need to have the new x86 virtualization capabilities (Intel VT or the AMD-V).
The guys are xtravirt.com have written a good starter guide. While they only mentionned how to run it with the Intel VT ( monitor_control.vt32 = TRUE ) flag, you can run them on AMD Opteron (AM2 or Socket F 1207pin). You need to use the monitor_control.svm_enable = TRUE. Thanks to the monitor_control.svn_enable switch, the virtual ESX 3.0.1 server will boot and be ready within 90 seconds.
This topic is pretty much dead for everything other than ESXi. If you are using a current version of VMware hosted products such as Workstation then this topic is the best for enabling Mac OS X support: =220750. Also MSoK has a summary topic here: =243274. I will create a new topic once I have done some new work on ESXi support.
For manual clarifications and additional updates from testing; e.g. ESX configuration please use your judgement as to whether to post this information. Also remember I do this in my spare time, and have full time job, family and other interests, so I will answer when I can.
Various issues have been raised with these processors. I have put together an experimental update to the package which uses the Voodoo 2 alpha 3 kernel. If you are having issues then please try the changes. If you are not experiencing any problems do not use this package until such time as it is rolled into the main one. If you have a non-Core processor but that is VT-x enabled such as P4D, then this may also be useful to you.
Of course feedback is great. Manual was a little hurried written over the last 3 days. If I didn't get it done now it would have been weeks before I could release as about to hit a busy spot at work and then family holiday.
2. Get the boot prompt requires some quick key presses as the timeout values in VMware's booter is very quick. The best way is to make sure that the guest has focus at the BIOS screen and hold down the Alt key (Windows/Linux) or Option key (Mac OS X). This brings up the prompt as shown in the first attached screenshot. Press the key you need and then immediately press the F8 key. This should give you the usual boot prompt. The timeout is hardcoded in the booter somewhere and would need to be patched to fix. I agree it is a bit fast but normally don't need it and so speeds up regular boots.
You need to check on the real machine's BIOS settings. I can't tell you what it will say as different BIOSes have different areas for configuring it. You can also run the program Processor Check for 64-Bit Compatibility to cross check the settings. _tools.html
If you want to verify whether or not your CPU is compatible, the best method is to use the VMware cpuid utility, available at: _utilities.html. It's an ISO image. Burn it to a CD, boot your machine and look for the line "Supports 64 bit VMware". If it's yes, you're good to go, if it's no, stop beating your head against the desk and find another machine. Side note: Xeon based HP DL380 G4's are a no go, but DELL PE2950 gen III with Xeon 5450's work peachy.
When you copy up the vmware-darwin-200 package to the ESX server, make sure that you put it on local storage and don't run the commands over and over again from a shared volume since your backups will be overwritten each time you run it on another server. Note that you will have to run this script on all the servers in a cluster in order for an OSX VM to be able to move freely and reboot from any of the ESX servers.
On ESX Server I used the LSI Parallel card and that didn't work. The disks show up, but as read only. Switching to IDE seems to be the only currrent choice on ESX for the moment. You're limited to 2 disks with that configuration, but you can always add the GlobalSAN iSCSI driver for direct iSCSI attachments later if required (or NFS or whatever turns your crank).
For ESX it is easy to upload to the actual COS and use it's storage, but ESXi is not the same as it resets the storage after reboot. I will do a little testing this week on that, but have a busy schedule at work.
A couple of secondary points to look into. I had originally installed my VM on the internal storage of the ESX Server and since this machine will be getting reinstalled, I copied the VM using the regular VMware tools over to an iSCSI volume. I tried to boot and ended up with the regular PXE boot so I checked the vmx file and found that it had been modified by ESX and replaced darwin-64 with other.
I'm going to try and rebuild a new VM on the iSCSI datastore and re-use the existing disk to see if that works, but this is an annoying problem since it means that you have to be extra careful and using the standard VMware tools to manage an OSX VM.
One tip from VMware is to switch of a the power management settings so that the virtual machine does not go to sleep. That can cause this issue. I have also used the Caffeine application to ensure the guest stays awake.
I'm pretty certain it is a problem with VMware due to something I have seen, but am under NDA. Not sure what to suggest next. Let me have a think about it, as maybe a different kernel may be possible. Voodoo kernel 2 alpha 3 is available and it is supposed to fix some FSB frequency issues with theses processors. Whilst it is possible to add to the CD image booting is a PITA.
7fc3f7cf58