A while back, a few of us figured out how to get the USB key with 3i beta (given away at VMworld) to run inside VMware Workstation:
http://communities.vmware.com/message/754336#754336
Now that ESX 3.5 is out, I see threads starting up about installing on a SCSI drive inside VMware Workstation:
http://communities.vmware.com/thread/116639?tstart=0
I cloned the 3i VM in Workstation, then with that clone, I added a SCSI disk and mounted the iso of the GA level of ESXS 3.5. After accepting is offer to change the disk type, I was able to then install and run ESX 3.5 from within the VM just fine.
I've attached a copy of my working vmx file.
Only tested for a few minutes, and a few gotchas already:
when I downloaded a virtual appliance right from its welcome page, it crashed ESX when the virtual appliance was powered on
when I pointed another Workstation VM (XP), one that had VIC 2.0.2 U2, I uninstalled, then pointed browser to bridged-networking IP of ESX 3.5 and installed new VIC 3.5, but it came up with an error at the end. However, it actually seemed to work fine, launched from desktop icon it created.
I hope this helps steer others in the right direction, and the speed/responsiveness was far better than I ever had the 3i working fyi.
Next steps, make another W2K3SP2 VM and install SQL 2005 and VirtualCenter 2.5 with VUM...also inside VMware Workstation (for portability and training and demonstration purposes at bandwidth constrained customer sites, and for "fun")
Just took a look at the flash video (Adobe Captive). Here are the steps for those that aren't able to render the flash video:
-
From the ESX or VC client, highlight the VM and select > Edit virtual machine settings
Select Resources tab
Un-check Unlimited in the right pane and lower Mhz count to 700
Select Advanced CPU in the left pane
Under Scheduling Affinity in the right pane > Select Run on processor(s):
Check "0"
Click OK to close VM edit window
Boot VM
-
I'll say this much - this isn't a great fix. Although it does allow for additional testing, VM performance is dismal at a minimum. I'm going to play with MHz and Affinity settings to see if I can get better results.
Thanks for the updates guys.
Check this out!
Got this link from another post by Vishy1
http://www.ntpro.nl/blog/archives/470-ESX-3.5-is-running-on-Workstation-6.5-Build-91182-!!!.html
Thanks Subatomic. The issue is that we cannot start vm's inside 3.5 on WS6.x
(at least not without p1$$-p00r performance)
Cheers,
Out of interest, has anyone got this working from a LINUX flavor running WS6.x then 3.5, or I am just assuming we are all a bunch of M$ users?
Ta
Note this appears to work with the latest WS6.5 Beta
The feedback on the blog site shows some positive results.
I just upgraded to Workstation 6.0.4 build-93057 for Linux. I also upgraded my Ubuntu to 2.6.24-18-generic SMP x86_64 GNU/Linux. I re-ran vmware-config.pl after the upgrades. NOW.... my networking on ESX 3.0.2 servers is messed up....
A fresh install of 3.0.2 produces a kudzu screen after startup and the VMKernel fails to load. An existing ESX VM causes "SCIOSIFHWADDR: device or resource busy" when i try to recreate the vswif. Google search suggests something's up with the attempt to generate a MAC address.
I have some work to do today before I get back to this, but i needed it to work on LifeCycle Manager...SUX... :o( (sad virtualization clown)
Dave
Subatomic -
If you read the blog, it says that VMs still do not start.... not good.
Dave
Hello Dave,
There are mixed comments on the blog page. There is reference to VMs not powering up early on in the article, but also Item 6 and 7 indicate positive results.
Thread move to the VMware Workstation forum
Tom Howarth
VMware Communities User Moderator
Subatomic -
I see that now. I first read it and stopped when I saw that a VM would not start. I am having similar issues now that I upgraded to 6.0.4. I was waiting to upgrade to 6.5 when the issue was fixed. I thought using 6.0.x would avoid the issue, but they broke it here too. I can't even get esx 3.0.2 to work. Time to downgrade.....
Incedentally, I am running an Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz according to /proc/cpuinfo. I don't think it has VT built in, so I think I'm sunk...
Dave
I'm running it on a stinkpad. I will check the bios again. i don't remeber seeing it. Thanks for the tip.
As for esx302 on ws6, it DID work on ws603, but broke in 604. At least for linux anyway. I am doing a debug dump now to send to support.
Dave
i just tried twice with an ESXi VM. when I start a VM inside the ESXi server, it PSODs and I get a workstation error:
VMware Workstation internal monitor error ***
vcpu-0:ASSERT vmcore/private/a20_shared.h:67
There is a problem in this version of VMware Workstation.
We rely on your feedback to improve the quality of our product. Please submit a support request that describes the problem at our Web page "http://www.vmware.com/info?id=8". Do not forget to attach the log file (/media/Portable_Drive/VMs/ESXi001/vmware.log) and the core file (/media/Portable_Drive/VMs/ESXi001/vmware-core.gz).
To collect data to submit to VMware support, select Help > About and click "Collect Support Data". You can also run the "vm-support" script in the Workstation folder directly.
We appreciate your feedback,
-- the VMware Workstation team.
This is similar to what is posted on the ntpro.nl blog.
I'm doing a support dump now. I am also going to (re)check the bios.
Just confirmed. VT is enabled in bios. I also upgraded it just in case. My support on WS6 expired....maybe it IS time to go to 6.5 beta... Any way, I have the debug-enabled logs if ayone wants them. I haven't had time to actually look at them myself to see what is up. ESXi gets a PSOD when starting a VM. ESX 3.02 and 3.5 get screwed up with networking, so I can't even connect to them with VC client. I never tried to power a VM on.,
Wonder why you still try to run ESX 3.5 in WS 6.0.*
As discussed over and over again ...
In WS 6.0.* you can run ESX 3.0.* - you can start VMs if your host has Intel VT or AMD SVM and you enable that in the vmx-file:
Intel:
monitor_control.restrict_backdoor = "true"
monitor_control.vt32 = "true"
AMD:
monitor_control.restrict_backdoor = "true"
monitor_control.enable_svm= TRUE
In build 91182 you can run ESX 3.5 or ESX 3.5i - you can start VMs if your host has Intel VT or AMD SVM and you enable that in the vmx-file with this new entry:
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "true"
If VMware sets monitor.virtual_exec = "hardware"
back to "software" then your CPU does NOT qualify
___________________________________
description of vmx-parameters:
I just figured that I would try 3.5 in WS6.0.4 (recent incremental update) to see what would happen....
I think I forgot the vt32 setting, which would explain my problem with ESX302 on WS604.
For some reason, I am "Unauthorized" on the beta refresh and just sent a PM to get me unlocked so I can download the new code.
Dave
For some reason, I am "Unauthorized" on the beta refresh
You have to re-register for the new beta. Also see .
oreeh -
Thanks - fixed my unauthorized problem....
Dave
OK...I'm a moron...I forgot that I updated the Ubuntu kernel and the reboot lost my "chmod a+rw /dev/vmnet3" which allows promiscuous mode to work in WS for linux. DOH! I need to put that in init.d
sorry to offend continuum..
Hi there,
Today I am a very happy man . I can finally run ESX 3.5 and open up VMs with Workstation 6.5 build 91182 with acceptable performance so I would just like to confirm what continuum reported earlier.
VMware Workstation 6.5 build 91182 with the extra line in ESX35.vmx works like a charm and I was able to Power On a VM without a glitch.
monitor_control.restrict_backdoor = TRUE
monitor_control.vt32 = TRUE
monitor.virtualexec = "hardware"_
The only problem was performance.
I have noticed that VMware Workstation build 91182 was running in debugging mode which had a clear impact on performance. It appears got sorted by renaming C:\Program Files\VMware\VMware Workstation\vmware-vmx-debug to something else and copying C:\Program Files\VMware\VMware Workstation\vmware-vmx to vmware-vmx-debug
Rgds,
J.