DonalB's Posts

Be wary of the stepping difference, if these are far enough apart setting NX flags at the vm level won't matter, although BIOS settings on the hosts should all be the same. I'm having the same ... See more...
Be wary of the stepping difference, if these are far enough apart setting NX flags at the vm level won't matter, although BIOS settings on the hosts should all be the same. I'm having the same issue on 5440 CPUs in the sam hp models boxes. Steppings on original CPUs in the cluster are 6 whereas for the latest cpus stepping is 10. This causes the vmotion error you listed. The downtime is required on the VMs and not on the hosts as the maskign is done at the VM config level, either directly on the VM in edit settings or globally in the vpxd.conf file in VC. The following KB articles detail some of this stuff. If you have ESX3.5U2 or later this is fixed, as EVC is turned on but downtime is still required for EVC if you enable it on the cluster I think. Best VMware about it for clarification. HTH DB
Hi, What version of VC do you have? I'm pretty sure that in earlier versions the % value being shown for the alarm is incorrect is actually measured as KBps by VC (this is fixed in VC2.5U... See more...
Hi, What version of VC do you have? I'm pretty sure that in earlier versions the % value being shown for the alarm is incorrect is actually measured as KBps by VC (this is fixed in VC2.5U2/U3) so the way the alerts are set means that although it looks like 80% usage it's actually triggered when you go past 80 KBps of usage, for example. Hope this helps DB
have come across this on a couple of 3.01 hosts and it seems to happen quite a bit (every 3-4 weeks), restart mgmt-vmware and reconfiguring for HA usually sorts out the disconnect. Seems to be ... See more...
have come across this on a couple of 3.01 hosts and it seems to happen quite a bit (every 3-4 weeks), restart mgmt-vmware and reconfiguring for HA usually sorts out the disconnect. Seems to be a memory leak in some HA agent components. Still haven't patched these boxes up to latest levels but expect that to fix it. HTH DB
Have been trying to find this out myself for a while, found this post http://communities.vmware.com/message/501161, which helps to some degree. Use the -s option with ls to see the block size s... See more...
Have been trying to find this out myself for a while, found this post http://communities.vmware.com/message/501161, which helps to some degree. Use the -s option with ls to see the block size so ls -lh <vmdk path> should show the size reported by the file and compare this to ls -1sh <vmdk path> and of it's smaller than the first value then it's a thin disk Cheers DB
To keep VMs running and not have to turn off HA you can set the default isolation behaviour of the vms on each host to leave powered on. This will mean HA doesn't work as quickly in the event of ... See more...
To keep VMs running and not have to turn off HA you can set the default isolation behaviour of the vms on each host to leave powered on. This will mean HA doesn't work as quickly in the event of a host failure but all the VMs won't get powered off when you take the switch offline. Might be something to consider HTH DB
You could look at using a virtual appliance from here http://www.vmware.com/appliances/ , there's one or two iscsi appliances that I've tested with before. It'd be possible to put together someth... See more...
You could look at using a virtual appliance from here http://www.vmware.com/appliances/ , there's one or two iscsi appliances that I've tested with before. It'd be possible to put together something that would work for testing the DR and HA but the OS in the VM may not run very well
Yep that's it then, you need to have shared Fibre Channel or iSCSI storage for vMotion, DRS and HA to work. They all operate on the premise that all ESX hosts can see the vmdk files etc and that ... See more...
Yep that's it then, you need to have shared Fibre Channel or iSCSI storage for vMotion, DRS and HA to work. They all operate on the premise that all ESX hosts can see the vmdk files etc and that in the case of vMotion or DRS al that is being copied across the vMotion network is the VM's active memory and state information otherwise it would take too long to copy a 10Gb vmdk from one host to another and in the meantime the Guest OS in the VM would be unresponsive. For HA shared storage is required as it is intended for use in a hardware failure scenario, so if you had an esx host fail due to a hardware failure (RAM, CPU etc) then the server will just crash, in that case ESX will not get time to copy VMs off to another ESX host, it'll just be turned off by the hardware going donw, bringing the VMs sitting on it's local disk with it. With shared disk, the ESX host will still go down but the other ESX host can see the VMs still sitting on the shared storage and start them back up.
Just noticed from your doc that you don't seem to have shared storage between the two esx hosts, at least that's how it looks. You have a VMFS LUN call VM1 and another called VM2. Without shared ... See more...
Just noticed from your doc that you don't seem to have shared storage between the two esx hosts, at least that's how it looks. You have a VMFS LUN call VM1 and another called VM2. Without shared storage then HA and DRS won't work unfortunately.
Also for HA to work you need DNS to be working correctly on the ESX hosts and VC, so can you resolve the hostname of both ESX hosts and the VC server from each of those servers. You may also find... See more...
Also for HA to work you need DNS to be working correctly on the ESX hosts and VC, so can you resolve the hostname of both ESX hosts and the VC server from each of those servers. You may also find it useful to use host entries in /etc/hosts on the ESX servers to make sure this is working as it should.
What was the test you were performing, should have said that you should try testing HA with this setting changed. Basically pull the plug on the ESX host that's running your VMs and make sure tha... See more...
What was the test you were performing, should have said that you should try testing HA with this setting changed. Basically pull the plug on the ESX host that's running your VMs and make sure that they start up on the other ESX host.
Hi, I notice from the screenshots that you've set your HA Host Failures allowed to 2. Maybe try setting this to 1 and rerun the tests? Cheers DB
Basically i think cloning is possible to do but as mentioned the ssl cert/key regeneration would be your problem and I'd personally hate to have to track down problems with communcation of the VI... See more...
Basically i think cloning is possible to do but as mentioned the ssl cert/key regeneration would be your problem and I'd personally hate to have to track down problems with communcation of the VIC or with VC because of ssl errors, reckon it'd be pretty nasty . For the patching, as someone post on the other post you mention there, VMTS Patch Manager is a good bet to look at for your environment as even if you cloned, you still have to manage updating them later. There are other sripts utilites for patching around the forums and most of them don't need you to reboot repeatedly, basically you can blast all the patches onto the box one after the othr and only reboot at the end. Cheers DB
Just beat me to it! there are also some other scripts that are esx server based which chieve the same thing. Cheers DB
Not cloned ESX servers before but off the top of my head the type of things you'd need to be wary of are the ssl keys generated for communication with VC and for us by the mui (what little there ... See more...
Not cloned ESX servers before but off the top of my head the type of things you'd need to be wary of are the ssl keys generated for communication with VC and for us by the mui (what little there is of it). /etc/vmware/esx.conf would also need to be changed, in fact I'd have a good look around in /etc/vmware/ for other files that might need to be changed. What i have done before is Kickstart configs and I think you get some deployment tools (Altiris??) with HP blades that would allow you use the KS file to install ESX on the blades. You can enable KS config on the ESX server itself or use something like this: http://www.xtravirt.com/index.php?option=com_remository&Itemid=75&func=fileinfo&id=8 Might give some better options. Maybe this post may help here: http://www.vmware.com/community/thread.jspa?messageID=685801&#685801 Cheers DB
Hi Ole, Trying a different JVM hasn't been done I'll try to get that done today. I have a circa 2Gb (75Mb zipped) core dump file for the JVM in use at the moment. Going to have a look through ... See more...
Hi Ole, Trying a different JVM hasn't been done I'll try to get that done today. I have a circa 2Gb (75Mb zipped) core dump file for the JVM in use at the moment. Going to have a look through it and anything interesting I'll post up. SR has been raised with VMWare, and also in parallel with Suse/Novell and BEA. I'll send on the SR number in a bit. (Link to JVM core dump file is in it so you can have a look yourself if you want) Cheers Donal
I have now , but there's nothing in there that helps as far as I can see. Did you have something in mind? Thanks Donal
ESX Host: HP DL585 (latest revs) , ESX 3.01 VM OS: SLES9 64-bit App server: BEA Weblogic 8.1 When starting weblogic app with no pre-allocation of mameory to VM, app grows RAM usage gradually... See more...
ESX Host: HP DL585 (latest revs) , ESX 3.01 VM OS: SLES9 64-bit App server: BEA Weblogic 8.1 When starting weblogic app with no pre-allocation of mameory to VM, app grows RAM usage gradually and all is fine. However when pre-allocating say 1.5-2.2 GB RAM in JVM settings (VM is allocated 4GB RAM in total), start weblogic app and within 30sec-5min java has crashed. This is reproducible within across two VMs with same setup but works fine on a physical host?? Have tried setting memory reservation on VM to all RAM it is allocated but to no avail. Anyone seen anything similar or have any suggestions about what might be causing this? Thanks DB (P.S. When running an strace on the jvm processes with the RAM pre-allocated it seems to work ok which seems to give a hint to something but not sure what!!)
Hi, Been seeing this in my logs on 1 host of a 3 host cluster. Every 30 minutes or so get this message, then 15 minutes later root logs out. May not be related but CPU usage was also through... See more...
Hi, Been seeing this in my logs on 1 host of a 3 host cluster. Every 30 minutes or so get this message, then 15 minutes later root logs out. May not be related but CPU usage was also through the roof on the COS with vmware-hostd taking all it could get. Host is an 8-way with about 10 VMs running on it so performance wasn't a major issue but was worrying me so instead of troubleshooting it any further I deided to shoot first and ask questions later and pulled the trigger on the mgmt-vmware services. After a restart (service mgmt-vmware restart) it looks to be back to normal in terms of CPU usage. Am keeping an eye on the logs and will get back if I find anything interesting. Cheers DB
Yep, you're absolutely correct! I guess I'm comfortable enough with allowing root access for ad-hoc stuff like vm copies, especially if you are copying to a vmfs as permissions on vmfs volumes... See more...
Yep, you're absolutely correct! I guess I'm comfortable enough with allowing root access for ad-hoc stuff like vm copies, especially if you are copying to a vmfs as permissions on vmfs volumes can cause headaches when trying to copy as a normal user (or so I've found!) Probably should have added an extra point to say once you're finished, reverse the changes to lock down the box again, will do that now maybe Cheers DB
You can allow root ssh (and thus scp,sftp) by doing the following: 1. Take a backup of /etc/ssh/sshd_config first just in case! 2. edit using vi or nano /etc/ssh/sshd_config 3. Find the line ... See more...
You can allow root ssh (and thus scp,sftp) by doing the following: 1. Take a backup of /etc/ssh/sshd_config first just in case! 2. edit using vi or nano /etc/ssh/sshd_config 3. Find the line that says PermitRootLogin and change the no to a yes, exit and save the file 4. Run the following command service sshd restart You should now be able to login as root vai ssh. As far as outgoing ssh, the poster above has the answer to that, iptables config does outbound as well as inbound filtering Cheers DB