That means N/A-... The info is only availabe for ESX VM Disks (pressing v) I think that this is mentioned somewhere in the Resource Management Guide for 3.5 /Rubeck
It seems that this error was supposed to be resolved in VirtualCenter 2.0.2 Update 3... Cut/paste from http://www.vmware.com/support/vi3/doc/releasenotes_vc202u3.html "VirtualCenter Does No...
See more...
It seems that this error was supposed to be resolved in VirtualCenter 2.0.2 Update 3... Cut/paste from http://www.vmware.com/support/vi3/doc/releasenotes_vc202u3.html "VirtualCenter Does Not Correctly Display New License Format This release fixes an issue where earlier versions of VirtualCenter are not able display licenses from license files issued since the release of VirtualCenter 2.5. On versions of VirtualCenter before 2.0.2 Update 3, the license files appear to install normally but log warnings such as "Chunk 'desc=ESX Server Enterprise' was not well formed, skipping" in the log files when license files of the new format are displayed in VirtualCenter. " Maybe your license server is not up to date..... I don't know. /Rubeck
Are all your ports on the pSwitch configured identical? I f yes I have a suggestion assuming:that more than 2 vSwitches exists. 1 for SC and the rest for VM's. (it seems to me like th...
See more...
Are all your ports on the pSwitch configured identical? I f yes I have a suggestion assuming:that more than 2 vSwitches exists. 1 for SC and the rest for VM's. (it seems to me like this is how it is configured) I would remove one of the pNICs from a VM vSwitch and move it to vSwitch where COS (vSwif) is confgured.. The syntax is from top of my head, as I dont have access to a host right now.. esxcfg.vswitch -l > Look for a VM vSwitch with multiple pNics esxcfg-vswitch -U vmnic# vSwitch# < Unlinks the pNic from the vSwitch esxcfg-vSwitch -L vmnic# vSwitch# < Links pNic to the Vswitch where SC is. Disconnect the "faulty NIC" so a failover can occur due to missing Linkstate status. This way you should be able to get the host COS back online and check things out using the VIClient /Rubeck
Dump the output of "esxcfg-info -n" on every host... For larger installations with already configured hosts, I would try to write a simple Powershell script which pulls this host info dire...
See more...
Dump the output of "esxcfg-info -n" on every host... For larger installations with already configured hosts, I would try to write a simple Powershell script which pulls this host info directly from VC. /Rubeck
I do not think you can create multiple VMFS volumes on the same LUN, due to the way ESX handles locks. It locks an entire LUN and not a partition. /Rubeck
Found it.... the issue was solved by patch ESX350-200802410-BG http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1003457&sliceId=2&docTypeID=DT_KB_...
See more...
Found it.... the issue was solved by patch ESX350-200802410-BG http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1003457&sliceId=2&docTypeID=DT_KB_1_1&dialogID=11140365&stateId=1%200%2011138599 /Rubeck
You cant expand an existing VMFS volume You have to create a new LUN using the 2 disks, and then you should be able to do an "extend". (not recommeded, IMO) /Rubeck
I dont know how the network part on your host is configured, but if you've dedicated pNICs to the SC have you then checked the link status? (esxcfg-nics -l) Have you tried to disable the E...
See more...
I dont know how the network part on your host is configured, but if you've dedicated pNICs to the SC have you then checked the link status? (esxcfg-nics -l) Have you tried to disable the ESX firewall as a test, to see if it then responds to ICMP? (service firewall stop) I do not think it will help with a "service mgmt-vmware restart" if it dosn't respond to ICMP at all. Running the above command might effect the running VM's if you have configured automatic start/ stop of VMs on the host. This issue have been solved in 3.5 U1, as far as I know. Just some ideas.. /Rubeck
Don't use "cp".... Do it by the book and use vmkfstools when working with .vmdks. If you're using shared storage the "cp" (and other standard tools) will result in unnessesary SCSI reservations....
See more...
Don't use "cp".... Do it by the book and use vmkfstools when working with .vmdks. If you're using shared storage the "cp" (and other standard tools) will result in unnessesary SCSI reservations. /Rubeck
I would check out the release notes for 3.02.. , to see "what's new". Maybe CheckPoint tested their product on 3.0.2 only... and for this reason they're not able to verify that it actualy wor...
See more...
I would check out the release notes for 3.02.. , to see "what's new". Maybe CheckPoint tested their product on 3.0.2 only... and for this reason they're not able to verify that it actualy works on 3.01.... Then again, if they say its not compatible with 3.0.1, there's gotta be some kind of reason for this which they are the only one to know about. So you should really pull the answer from CheckPoint directly, IMO. /Rubeck
This is usally because of a DNS issue.... For testing, try to put in the FQDNs for your ESX host, into your local host file on your client PC. When launching a Remote Console from VC the clie...
See more...
This is usally because of a DNS issue.... For testing, try to put in the FQDNs for your ESX host, into your local host file on your client PC. When launching a Remote Console from VC the client needs to be able to resolve the FQDN name of the host which the VM runs on, otherwise you'll see a error like this. /Rubeck
I'll bet you've already tried this, but have U tried to log on VC as the local admin of the VC server, to see if this issue persist? I've some weird persmission issues.. Just an idea...
See more...
I'll bet you've already tried this, but have U tried to log on VC as the local admin of the VC server, to see if this issue persist? I've some weird persmission issues.. Just an idea... /Rubeck
I would think that's because one dir contains the VMs .vmx file and the other one contains the .vmdk disk(s) Unregister the VM from inventory. Move the .vmx file to the dir with the .vmdk ...
See more...
I would think that's because one dir contains the VMs .vmx file and the other one contains the .vmdk disk(s) Unregister the VM from inventory. Move the .vmx file to the dir with the .vmdk files... Re- register. /Rubeck
I don't know really, but a guess would be that it is defined in /etc/logrotate.conf Various switches for logrotate.conf can be found here http://articles.techrepublic.com.com/5100-10878_11-1052...
See more...
I don't know really, but a guess would be that it is defined in /etc/logrotate.conf Various switches for logrotate.conf can be found here http://articles.techrepublic.com.com/5100-10878_11-1052474.html /Rubeck
Hi.. If you, for example, unregister a VM and then create new VM with the same name on the same LUN the folder will be named VMname_1. (in cases where you want ESX to create a new .vmx file f...
See more...
Hi.. If you, for example, unregister a VM and then create new VM with the same name on the same LUN the folder will be named VMname_1. (in cases where you want ESX to create a new .vmx file for an existing VM, this is usally what some people do) The .sf files represent the LUN's metadata, which you do not wanna mess around with /Rubeck