I found a few things, for one SQL needs to be configured for Native SQL Client DSN (I had to reconfigure the DSN). Then it will upgrade the database schema.
Then this takes quite a long time to upgrade the database. That's all I found for now.
[11:27a EST - The VIM (Virtual Infrastructure Management) install was fine. Everything looks good for client install (Vista 32-bit)
3.5 Server I upgraded one of my servers, and I had invalid sda (even thought it boots fine with 3.02). I tried upgrading, no good. I am now doing a NEW install (retaining current VMFS configurations). Looks like I will be here a while cleaning up .. but hey, at least I can test 3.5.
I have it installed and working about the build scripts to reflect any changes
Steve Beaver
VMTN Forum Moderator
*Virtualization is a journey, not a project.*
I did manage to get everything working again. ESX 3.5 is definately smoother and more responsive, not sure about that much faster, but it seems like it. Remote Desktop to a VM is VERY fast, but I hestitate to say "faster" because it was 1 VM, and I have to wait for my VM's to migrate over to this machine to really test the performance (yes, I could force it, but I wanted to specifically test everything to ensure automated functions were working).
The SQL upgrade was just painful. I had to scrap the entire database, and start over. which didn't take that long, thankfully I had a backup of my environments, and I was able to copy the same setup, but it was time to clean house anyway. So everything looks real good. there are many new features and some updates that were needed like the performance meters were much slower, but now they are almost instantaneous. I like the new look (annoying "get started tabs") other than that, a definate improvement. Everything is working well.
A few of things that I noticed are listed below (I'm installing with the UDA appliance):
1. Checking the VMotion checkbox no longer appears to work using vimsh -n -e "/hostsvc/vmotion/vnic_set portgroup2"
My guess is that the InternalID has been eliminated or changed, because the output of an esxcfg-vswitch -l no longer lists InteralIds at all.
2. Adding the nics to a vSwitch - The second and subsequent NICs are added as standby nics
My 3.0.2 installs defaulted to all added NICs being active. Maybe a change of the defaults? I'm poking around now to try to find a way to script this...
3. Rolling failover no longer gets set using vimsh -n -e '/hostsvc/net/vswitch_setpolicy --nicteaming-rollingorder=true vSwitch0'
Poking around on this one, too.
Hi
I've written about my ESX 3.5 / VC 2.5 installation: http://www.gabesvirtualworld.com/?p=4
Did have a small SQL problem, but was able to migrate without losing data.
Gabrie
Changed the URL to point to my new site
Gabrie, I'd like to read what you found, but I'm blocked from seeing your site from my part of the world. Any chance you could PM me with your notes?
Where could I find a link for download 3.5?
Best Regards, Magnus
It is not yet available.
Be warned it's not the final release.
Message was edited by: oreeh
Removed the link since this is not the GA release.
Oliver Reeh
VMware Communities User Moderator
2. Adding the nics to a vSwitch - The second and subsequent NICs are added as standby nics
My 3.0.2 installs defaulted to all added NICs being active. Maybe a change of the defaults? I'm poking around now to try to find a way to script this...
This is what I am doing to get around that. By default now one nic is active and the other is standby. First I make one nic active using vimsh which but the other nic as unused. Then I do the command again to make both nics active
service mgmt-vmware restart
sleep 20
vimsh -n -e "hostsvc/net/vswitch_setpolicy --nicorderpolicy-active vmnic0 vSwitch0"
vimsh -n -e "hostsvc/net/vswitch_setpolicy --nicorderpolicy-active vmnic0,vmnic1 vSwitch0"
Is that working for you in 3.5? I get errors on the second vimsh statement, so I just wanted to verify...
Getting off work now, but I'll crank back up and retry in the morning.
I am running the build again to double check
Hello,
The "vimsh" syntax have change but most of the command still work. I get information about something will be advailable later from VMware to help on scripted installation of ESX
Yeah I am getting the error now also. For the set of commands to work on of the adapters must be a member of the unused adapters and not standby
1. Checking the VMotion checkbox no longer appears to work using vimsh -n -e "/hostsvc/vmotion/vnic_set portgroup2"
I found the change that need to be done for this to work again. Assumning you only have 1 vmkernel port use this command to check the check box
vimsh -n -e "/hostsvc/vmotion/vnic_set vmk0"
Notice the only difference isthe vmk0
Insufficient arguments.
Usage: vnic_set vnic
I then got the value from this
(vim.host.VirtualNic) [
(vim.host.VirtualNic) {
dynamicType = <unset>,
device = "vmk0",
key = "key-vim.host.VirtualNic-vmk0",
portgroup = "vMotion",
spec = (vim.host.VirtualNic.Specification) {
dynamicType = <unset>,
ip = (vim.host.IpConfig) {
dynamicType = <unset>,
dhcp = false,
ipAddress = "192.168.122.9",
subnetMask = "255.255.255.0",
},
mac = "00:50:56:7a:4f:33",
},
port = <vim.host.PortGroup.Port:key-vim.host.PortGroup.Port-16777221>,
}
Steve Beaver
VMware Communities User Moderator
*Virtualization is a journey, not a project.*
Good stuff! I don't know how in the hell you came up with vmk0, but that'll give me a boost on the other stuff I want to try. I'll post findings as I come by them.
Yeah I am getting the error now also. For the set of commands to work on of the adapters must be a member of the unused adapters and not standby
This does appear to work, but the only way I've found to get the adapters into the "Unused" group is through the GUI. Ideally, we should either be able to add them programatically to the Unused group so that they can be subsequently added to the Active group, or maybe be able to specify the desired group when adding the nic to the vSwitch. Either way it's pretty much academic, at this point, I guess...
Here's something interesting... One of the things I was trying to do was set the rolling failover to "yes" which I couldn't seem to do. Upon further inspection, the spot where "rolling failover" used to be in the GUI is now named "Failback." The default in 3.x for rolling failover was no (which I think is a bad thing) and the default in 3.5 for "Failback" is no (which I think is a good thing.) If I'm reading this right, rolling failover in 3.x set to yes (non-default) is the same thing as 3.5 failback det to no (default.)
Sanity check, anyone?
EDIT - I found the below in the new 3.5 doc, but it really sounds backwards. Typo or just funky, you decide...
*
Failback - Select Yes or No to disable or enable failback.
*
This option determines how a physical adapter is returned to active duty after recovering from a failure. If failback is set to No, the adapter is returned to active duty immediately upon recovery, displacing the standby adapter that took over its slot, if any. If failback is set to Yes (default), a failed adapter is left inactive even after recovery until another currently active adapter fails, requiring its replacement.