I have an ESXi which contains some VMs. I want to use the built in template 'Template Virt VMware' in zabbix to discover all VMs and their related Items, but I don't know what should I write for {$URL} in MACROS!!
I googled and found that I should write the webservice SDK url. But what is the correct url?
I use the following:
https://serverip/sdk/vimService.wsdl in which 'serverip' is the ip of the ESXi but it didn't work!
Any help is appreciated.
According to the documentation you can't monitor vms on the server using this method.
In this method you should enter https://esxi-server-ip/sdk for {$URL}
It will manitor your esxi host it self, for manitoring the virtual machines, you should to install zabbix agent on them or use something like snmp or ipmi for each of them
Related
I have a Google Cloud compute instance running with Ubuntu 18. We had wireshark running tracking another problem and we noticed that every minute something is accessing the meta data server. Three requests every minute:
GET /computeMetadata/v1/instance/virtual-clock/drift-token?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=False&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/instance/network-interfaces/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=77&wait_for_change=True
In call cases, the wireshark says the source is the IP of my instance, and the destination is the 169.254.169.254 which is the Google metadata server.
I don't have any code we have written that is accessing the server. The first one makes me think that this is some Google specific software that is accessing the meta data? But I haven't been able to prove that. What is worrisome is that the response for the third one contains ssh keys. Also, every minute seem excessive.
I see another post talking about scripts in /usr/share/google, but I don't have that directory. I do see that google-fluent is installed. I also see a installed snap for google-cloud-sdk. Could one of those be it? I don't recall installing them, AFAIK, I am not using it, so if that is it, what is the harm in uninstalling it?
You do not have a problem to worry about. The metadata server is private to your instance. The Google VM guest environment software and Stackdriver (fluentd) are making requests to the metadata server to get credentials, detect changes (new SSH keys), set the clock, etc.
The IP address 169.254.169.254 is an IPv4 Link Local Address. Only your VM has a route to that network.
Compute Engine Guest Environment
Do not attempt to uninstall the Guest Environment. You can remove Stackdriver, but I do not recommend that. Stackdriver provides logging and monitoring features that are very useful.
I have been trying to setup Docker in Windows Server 2016 in an AWS instance to run an IIS program.
From this question,
Cannot access an IIS container from browser - Docker, IIS has been setup inside a container and it is accessible from the host without port mapping.
However, if I want to allow other users from the Internet/Intranet to access the website, after Google-ing it, I guess we do need port mapping...
The error I have encountered in port mapping is given in the above question so... I guess using nat is not the correct option. Therefore, my team and I tried to create another network (custom/bridge) following instructions from
https://docs.docker.com/v17.09/engine/userguide/networking/#user-defined-networks
However, we cannot create a network as follows:
; Googled answer:
https://github.com/docker/for-win/issues/1960
My team guessed maybe its because AWS blocked that option, if anyone can confirm me, please do.
Another thing that I notice is: when we create an ECS instance in AWS,
So... only default = NAT network mode is accepted in Windows server?
Our objective: put the container hosted IIS application to Internet/Intranet in Windows Server 2016...
If anyone has any suggestion/advice, please tell me, many thanks.
I have a windows 10 VM in azure. I connect to this machine RDP. Because most of the time this machine is not in use (I'm not using it) I'd like, in order to save the costs, to shut down it.
My issue is to get back, to connect to it RDP after that. How do I start the machine remotely?
If you shutdown VM inside VM, you continue to pay for your VM.
If you shut down a VM from inside ( using Windows power options) or
through PowerShell by calling ShutdownRoleOperation with
"PostShutdownAction" equal to "Stopped".
More information please refer to this FAQ and this link.
You should use Portal or PowerShell to stop your VM.
If your VM is stopped(deallocated), you could use PowerShell to start your VM.
Start-AzureRmVM -ResourceGroupName $myResourceGroup -Name $myVM
More information about manage Azure Virtual Machines using PowerShell please refer to this link.
Also, you could start your VM on Azure portal. More information please refer to this link.
Notes: If you don't set static Public IP, the IP address will change.
this question has been asked before several times, but never anyone brought up any reasonable solution.
? Is there any way, from within a Windows guest, to find the hostname or IP address of the ESX host ?
The scenario is as follows:
I am working on a virtual host (Windows 7 guest, I have Admin privileges on the guest, VMWare Tools are installed, I can install PowerCLI or any other tool if I want to [though I assume it wouldn't help]).
Now I need to contact the administrator of the underlying ESX server. If I can find out either the ESX server name, or the IP address, I can find out whom I must contact.
Is there any way from within the client to find either the ESX host name or its IP address?
Thx, Armin.
P.S. please don't - like many other postings do - suggest workarounds requiring that I do
a) set any info on the host side which I can later query from the client - cannot do this in my scenario, and to have anyone else do this I need to find the responsible person first.
b) say it cannot be technically done for some reason (including "sandbox" and "security") - I have VMware Tools installed, look at the "VMWareToolboxCmd.exe stat" command - it can retrieve various infos from the underlying host, like the clock time or the speed of the CPU, so there are ways to communicate with the host, but I failed to find any command to retrieve the host name or IP address.
c) use PowerCLI, VSphere client, etc. As far as I know all those approaches require that one knows the ESX hostname and has login credentials for the host, not the guest. I don't have login credentials for any ESX machine in the company.
I am migrating my vCenter Server 5.5 to a new server (databases have already been moved to a new SQL server and all is OK on existing vCenter Server 5.5 implementation). When I begin the simple install process on the new vCenter Server host the Single Sign-On component presents me with an IP address of 10.10.10.117 as the ip address of the FQDN file01.xxxxxxxxx.com. This is the iSCSI interface address. I need it to use the 10.1.1.17 ip address that is the address of the production NIC that the ESXi 5.5 hosts will be communicating with. I have already changed the binding order of the NIC cards and flushed the DNS cache. I also added file01.xxxxxxxx.com with the proper IP address to the hosts file and also file01 to the hosts file. Still, during the install, 10.10.10.117 is discovered. Thanks in advance! Babak C.
Just to get a quick clarification...are you freshly installing vCenter 5.5? Or are you migrating an existing vCenter server to a new host and using the update utility to upgrade? I am assuming you are doing a fresh install based on your details about the SQL server and SSO. Here is my suggestion, in case it is a fresh install.
We had a similar problem with 5.5 on a new install where the IP address that was discovered during the actual vCenter Server install was that of the public facing NIC which we never use for management traffic (it's for internet access on the vC server, for update manager, etc.)
The strange thing is that there had NEVER been an entry in ANY of our DNS servers for that interface. So, after looking into it a little bit, I started thinking the IP that was returned during install was not a DNS result at all. Rather, it was (most likely) simply gathered from the interfaces on the Server based on binding order (e.g. which NIC has the default gateway.)
In order to save having to uninstall and clean up a major mess if the install completed wrong, we stopped and got in touch with VMware support. They suggested we clear all of the temporary files both in the standard "temporary" folder on windows as well as under /ApplicationData/vmware/xxx, where 'xxx' would be whatever product is giving you trouble and HAS NOT been FULLY INSTALLED* (e.g. you started the install and noticed the incorrect IP, so you terminated the installer and there is metadata and cached files remaining from the partially run install).
Basically, what we had to do, was clear the temporary files and then make sure the NIC Binding Priority was correct (so you should check in Network Adapters|(press-alt)|Advanced Settings. Make sure the correct binding is checked (e.g. if you don't use IPv6 on the private network, clear it) and make sure that the Windows Network is at the top of the priority list on the second pane of the advanced settings. This helps tremendously with SSO by making sure the Windows Network stack is the first queried when you are signing in and SSO must submit a kerberos ticket to the AD DC for validation.
It is possible, that once you delete the partial install files and temporary files and fix the network settings (probably be a good idea to reboot as well), the next time you run the installer you might have success.
I will try to check this post later to see if it helped you at all... or it I just succeeded in making your life even more difficult (which I certainly hope not!) :)
One more thing...prior to initializing the installer, open up a PS session, perform ipconfig /flushdns and then ping the hostname of your vCenter server in order to get it in the DNS cache. You should also perform the following:
nslookup
NS>{your vcenter server IP address}
/* make sure the resulting hostname is correct..this ensures your PTRs and rDNS is working correctly. vCenter HEAVILY relies on accurate reverse DNS configuration...then do the following lookup for forward DNS */
NS>{your vcenter server FQDN}
Hope it helps. Best of luck my friend!
SIETEC