I've been investigating this command... to create VM Kernel switches from the COS....
It works pretty well - but one thing I've noticed is that there doesn't seem to be switch for enabling VMotion on the switch... or setting the default gateway value - which the VI client does prompt you do...
Does any one know of way of setting these parameters from the COS?
Regards
Mike
Secrets don't make friends!
As for the SDK, I think between some basic scripting and the SDK, you can do almost everything short of the "super-secret" stuff we find out by trail and error. I have some ideas that I want to try out so I will know soon enough.
Some guy this week if i'd considered putting a paypal
donate button on my site. I did this for a while and
got pricely one donation of $10 Oz dollars.
What's $10 New Zealand dollars worth, maybe 15 cents American?
OK, I just looked it up, and it's really about three and a quarter British pounds. Does that even buy a pint of cold, frosty adult beverages that you chaps over there insist on drinking warm?
I would make a comment about it being pocket change, but the British monetary system's lowest paper note is 5 GBP ($9.25 US) versus the paper dollar here, so your pocket change is actually worth something and ours isn't. On the plus side for us, walking around with 20 GBP pounds in our pockets doesn't weigh like, um, 20 pounds, and I don't even want to think about how strip clubs work over there, since patrons can't slip dollar bills into performer's costumes like they do here...
Hmm - Oz is not NZ
Translation: Australia is not New Zealand
Example: North America isn't Canada
Oh and we'd be able to buy almost 3 beers with $10
\[New Zealand $ that is]
John, I agree. These tools are not just throw-ins for advanced users, but essentials for all large installations. I am thrilled that they are there. This is so much better than SIGHUPping processes. I guess we will have to figure out some of these answers on our own and share results.
Mike and everyone-
I got this one figured out this afternoon! Mike has all of the correct steps except for one. We need to associate a particular portgroup with VMotion to tickle the checkbox. Add the following lines to your /etc/vmware/hostd/hostsvc.xml
You can find the UID of your VMkernel portgroup by looking at the portgroup configs in /etc/vmware/esx.conf. For example . . .
/net/vswitch/child\[0000]/portgroup/child\[0002]/prettyName = "VMkernel"
/net/vswitch/child\[0000]/portgroup/child\[0002]/shapingPolicy/enabled = "false"
/net/vswitch/child\[0000]/portgroup/child\[0002]/teamPolicy/linkCriteria/beacon = "ignore"
/net/vswitch/child\[0000]/portgroup/child\[0002]/uid = "portgroup3"
In the above case, my VMkernel port group UID is portgroup3. So, to enable VMotion from the CLI, here is what I did . . .
Edit /etc/vmware/hostd/hostsvc.xml to include the VMotion portgroup association. With portgroup3 from above, here is how it looks . . .
Next, we need to enable VMotion just as Mike pointed out . . .
esxcfg-advcfg -s 1 /Migrate/Enabled
If you want to implement the change without restarting, you need to SIGHUP the hostd process. I would recommend disconnecting the host from VC first so that you do not have to wait to reconnect. Then run these commands . . .
ps -ef | grep hostd
\** get the PID for hostd from the above command and insert below **
kill -SIGHUP PID
Then reconnect the host in VC and voila, VMotion is enabled.
The nice thing about this is that it should work seamlessly for automated installs. I will be adding something similar to the following commands to my %post section in my ks.cfg . . .
esxcfg-vswitch -A "VMkernel" vSwitch0
esxcfg-vmknic -a "VMkernel" -i 192.168.2.202 -n 255.255.255.0
esxcfg-route 192.168.2.1
sed 's,/etc/vmware/hostd/hostsvc.xml
esxcfg-advcfg -s 1 /Migrate/Enabled
In this circumstance I don't think that we will need to SIGHUP the process. So VMotion should be properly enabled in a completely automated fashion. We should be able to attach the host and have VMotion enabled from the get-go.
Yay! I will report back the success/failure of our automated installs by the end of this week.
Andrew, Many thanks for sharing this. This works, now to stream into my scripted build and I should be well on the way!
My pleasure! It's fun discovering all of the new hiding places for various settings.
Andrew...
Getting back to this thread - and following up on the instructions...
Quick question - the use of kill -SIGHUP, would service mgmt-vmware restart work just as well... is their any reason you choose to use kill -SIGHUP?
Regards
Mike
Hmmm I had this working . Now for the life of me I'm not sure what the issue is.
One thing I have noticed if you restart mgmt-vmware and then reconnect the host back to VC the vmotion settings are removed from the hostsvc.xml file.
If I use kill -SIGHUP I can't connect the host back to VC at all!
Mike have you been able to try this in depth?
Well, i tried this the other day (on a unclean server) and it worked like a charm... did seem to take awhile to take effect - and of, course I changed to many things similantously to work out if it was the kill or the mgmt.vmware restart that did the trick. The other variable is this was not a clean server and had previously been manually configured for VMotion...
Talk about paranonia or what - I wish i could have a REDO/undobale disk on the ESX server itself... Hey, that's a concept huh... COS as completely a VM with snapshot modes!!!
I am wiping stuff this week and doing clean installs as part of my dev for the new Vi-3 Install and Configure course. I have two boxes - and i plan to do the labs one (following them to letter) and wierd and wacky stuff (like this) to confirm that it works...
I will come back to this thread with my findings...
Regards
Mike
I have used this stuff extensively as well. It seems to work great.
To answer Mike's question, the use of kill -SIGHUP forces a reload of the settings, without the current settings getting written out. Though I have streamlined things a bit.
For starters, I have since discovered, like everybody else, that we cannot run the esxcfg . . . commands in the %post section of the kickstart. So, all of this stuff needs to be run from rc.local on first boot.
Second, the kill command can be automated and scripted without the need for a ps -ef command. Use the following after you update the VMotion settings.
killall -HUP vmware-hostd
Fun stuff!
Mooihoek-
Be sure to disconnect the host from VirtualCenter before running the kill command. It then takes less than a minute for hostd to reload. Can you connect the host back to VC after a restart? Does it retain the VMotion setting?
Andrew,
Still I have problems trying to get this working. I'm running the following script after I have build a fresh copy of esx.
sed "s,
</vmotion>
</configRoot>," < /etc/vmware/hostd/hostsvc.xml > /etc/vmware/hostd/hostsvc1.xml
mv /etc/vmware/hostd/hostsvc1.xml /etc/vmware/hostd/hostsvc.xml
esxcfg-advcfg -s 1 /Migrate/Enabled
Then I disconnect VC
The I run killall -HUP vmware-hostd
Reconnect VC but the settings are lost.
Am I doing something incorrect?
Even when the above script is run in my build the config changes are being written to the esx.conf and hostsvc.xml files, but they are removed when the server is finally built.
I think this problem might be that were touching the configuration files "round the back" to the VI client... I've heard of people having problems with the VI client over-writting the hard-code changes to the VMX file...
It's like we have the file open twice (once in GUI and the other the CLI) which ever gets closed last over-writes the others change...
Perhaps to make an "authoritive" change to these configuration files - we need to stop the hostd (which would kill any VI Client connections); make the edit and then restart the hostd service...
Just a theory...
Regards
Mike
Are we able to stop hostd ?
Well, i see no reason why not...
service mgmt-vmware stop
This will kill of any VI client management of the ESX host... I'm just guessing this might be a work around...
So I maybe barking up the wrong tree...
Regards
Mike
Ok it appears not matter what I try, either disconnecting the host from VC and then running killall -HUP vmware-hostd or stopping service mgmt-vmware stop clears any settings configured.
Has anyone else made any progress?
Bump.
Has anyone come up with a way to keep the setting?
I have the same problems as the above posts.
Thanks.