Hi all, For a script I am building, I'm looking to get cluster statistics (CPU and memory resources) via PowerCLI. Specifically these resources: It needs to implemented in the script like...
See more...
Hi all, For a script I am building, I'm looking to get cluster statistics (CPU and memory resources) via PowerCLI. Specifically these resources: It needs to implemented in the script like this:
$Targets = @("Test Cluster")
foreach($clus in ($Targets))
{
$TotRAM = 192
$TotCPU = 35
The variables $TotRAM and $TotCPU need to be dynamically filled. How can this be done? Thanks, Tom
You could try running services.sh restart to ensure every daemon is restarted, or even reboot the entire host. I think there is a process locked on this datastore, but it's hard to verify remotel...
See more...
You could try running services.sh restart to ensure every daemon is restarted, or even reboot the entire host. I think there is a process locked on this datastore, but it's hard to verify remotely.
If you are certain no VM's are running on the host in question, you could do a kill -9 6458291 && kill -9 13392045 to kill the proces. Then (if the VM didn't die :smileysilly:) try unmounting aga...
See more...
If you are certain no VM's are running on the host in question, you could do a kill -9 6458291 && kill -9 13392045 to kill the proces. Then (if the VM didn't die :smileysilly:) try unmounting again.
Those would be VMFS meta files so quite frankly there shouldn't be a reason not to remove this datastore. Is it possible that the the datastore on the other host is used as a swap datastore? Conf...
See more...
Those would be VMFS meta files so quite frankly there shouldn't be a reason not to remove this datastore. Is it possible that the the datastore on the other host is used as a swap datastore? Configuration -> Software -> Virtual Machine Swapfile location? Or perhaps a log directory (although there should be log files present then) Configuration -> Software -> Advanced Settings -> Syslog? You could also try the unmount while tailing /var/log/vmkernel.log (tail -f /var/log/vmkernel.log)
Can you do ls -allh via SSH in the datastore? So, in steps 1) Connect via SSH to the host that will not unmount 2) do cd /vmfs/volumes/<name of your datastore> 3) do ls -allh And share th...
See more...
Can you do ls -allh via SSH in the datastore? So, in steps 1) Connect via SSH to the host that will not unmount 2) do cd /vmfs/volumes/<name of your datastore> 3) do ls -allh And share the output.
Allowing the setting in GhettoVCB would be a solution however it might be better to ensure that the VM does not use those delta VMDK's by indeed shutting down the VM, creating a temporary directo...
See more...
Allowing the setting in GhettoVCB would be a solution however it might be better to ensure that the VM does not use those delta VMDK's by indeed shutting down the VM, creating a temporary directory and starting the VM again. If the VM does not give errors during the power on, the delta VMDK's are not used. The fastest way to test this is by: 1) Shutdown the VM 2) SSH to the host and go into the virtual machine working directory using the cd command. 3) Create a temporary folder (mkdir tmp). 4) Move the delta VMDK's there (mv chw-vm-02.cheeswrights.local_1-000001-delta.vmdk chw-vm-02.cheeswrights.local_1-000001.vmdk tmp) 5) Power on the VM again 6) If the VM powers on and everything appears to be working as expected, you can remove the tmp dir from the VM working directory (rm -rf tmp).
It seems there is no support for this motherboard / NIC, if there were custom drivers available, you could build a custom ISO. Sadly, this is not the case here.
John, I know, that shouldn't be a problem. You can just consolidate the disks. The reason it mentions this, is that when a snapshot is made, a new delta vmdk (VM disk file) is created. All new...
See more...
John, I know, that shouldn't be a problem. You can just consolidate the disks. The reason it mentions this, is that when a snapshot is made, a new delta vmdk (VM disk file) is created. All new changes from that point are saved in that new VMDK, but since you aborted the snapshot process, the VM is most likely running on a delta disk but the snapshot database does not report a successful snapshot. Let me know if it works out for you,
Hi John, No worries, you can just consolidate the snapshot. I've never seen this go wrong. If that shouldn't work, try creating a snapshot and doing a delete all from the snapshot manager wind...
See more...
Hi John, No worries, you can just consolidate the snapshot. I've never seen this go wrong. If that shouldn't work, try creating a snapshot and doing a delete all from the snapshot manager window.
How do you mean tuning? Sure, you can configure CPU affinity and lock down a VM to specific cores, but the VMkernel does a damn good job of scheduling the CPU when and where needed. So, my advice...
See more...
How do you mean tuning? Sure, you can configure CPU affinity and lock down a VM to specific cores, but the VMkernel does a damn good job of scheduling the CPU when and where needed. So, my advice would be to stay away from stuff like that.
So you want to run the test directly on the ESXi server? There isn't that much overhead in running it via a VM and VMware has a nice prepackaged appliance for it which will show you everything yo...
See more...
So you want to run the test directly on the ESXi server? There isn't that much overhead in running it via a VM and VMware has a nice prepackaged appliance for it which will show you everything you need to know: I/O Analyzer &#8211; VMware Labs
The only thing you perhaps lost are some specific CIM monitoring sensors for stuff like the hardware. I don't know if this is retained over the upgrade. Could you check this and let me know, I'm ...
See more...
The only thing you perhaps lost are some specific CIM monitoring sensors for stuff like the hardware. I don't know if this is retained over the upgrade. Could you check this and let me know, I'm curious to see the result.
That would be the Nexus 1000V checking the vSwitch configuration. I see this in some environments too, not really something to worry about. I couldn't find any solid backing that a problem is occ...
See more...
That would be the Nexus 1000V checking the vSwitch configuration. I see this in some environments too, not really something to worry about. I couldn't find any solid backing that a problem is occurring here.
There is some overhead associated with hot add, but it seems to fit well in a virtualize first strategy as it offers the scaleable solution that's needed in 2014.
The fact that the deamon shows as N/A is not very relevant. The service is running and the firewall is opened. You should be able to access your host via SSH.
