Pages

cli remote management of ESXi virtual machines over ssh

One of the ways to manage ESXi virtual machines is through vim-cmd commands. You can look at a quick tutorial of the command here.

Let's say there are a multitude of ESXi servers in your environment and you'd like to manage some virtual machines through cli.
One way to do this is to run vim-cmd commands over ssh. For example, I have 2 ESXis named in the example esxi1 and esxi2. On both of them I have one VM:
~$ ssh root@esxi1.localdomain "vim-cmd vmsvc/getallvms"
Vmid             Name                                         File                                  Guest OS       Version             Annotation
7      Linux                       [datastore1] Linux/Linux.vmx                                 debian6_64Guest    vmx-08

~$ ssh root@esxi2.localdomain "vim-cmd vmsvc/getallvms"
Password: 
Vmid           Name                                      File                                  Guest OS        Version             Annotation
13     VSRX                   [datastore1] VSRX/VSRX.vmx                                   otherGuest          vmx-09    VSRX OVF Template
So, this works fine and nice and actually there's nothing special about it. It's just running remote commands over ssh.

If you'd like to make things more easy, you can use ssh public key authentication for the remote esxi hosts (no need to type in the password every time you want to run a command).
I wrote some bash functions to make it even easier (to remember) and shorter to type.
This is what I have among other functions and things in my .bashrc file:
function start_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.on" "$2";}
function stop_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.off" "$2";}
function reboot_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.reboot" "$2";}
function getallvm () { ssh root@${1}.localdomain "vim-cmd vmsvc/getallvms" ;}
function powerstate_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.getstate" "$2";}
function getnetwrorks () { ssh root@${1}.localdomain "vim-cmd vmsvc/get.networks" "$2";}

How to remove Juniper ethernet encapsulation from pcap packet capture

When capturing packets on a Junos device, the output packet capture will include a Juniper ethernet header.
Example of such capture:


tcpdump -c1 -nvvr capture.pcap

reading from file JTAC.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)

14:58:06.569634

 Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16

   Device Media Type Extension TLV #3, length 1, value Ethernet (1)

   Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)

   Device Interface Index Extension TLV #1, length 2, value 149

   Logical Interface Index Extension TLV #4, length 4, value 872

 -----original packet-----

     ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28

To remove this header we need to chop the pcap [-C]  (in my case the first 22 bytes) , adjust the frame length [-L] and specify that the new frame type [-T] (ethernet in my case). I am using editcap version 1.12.1 and the default output type for the new pcap is pcapng. As I can see there's a problem when converting with this output type, so I am using libpcap as the output type.


editcap -C22 -L -F libpcap -T ether capture.pcap cap_libpcap.pcap


As you can see the Juniper ethernet header is  gone.


tcpdump -c1 -nvvr cap_libpcap.pcap

reading from file cap_libpcap.pcap, link-type EN10MB (Ethernet)

14:58:06.569634 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28

Recovering corrupted gzip files. gzip: compressed_file.gz: unexpected end of file


A tool to recover gzip corrupted compressed files is gzrecover. This comes with in the recovery toolkit package gzrt.

$gzip -d compressed_file.gz
gzip: compressed_file.gz: unexpected end of file

$file compressed_file.gz
compressed_file.gz: gzip compressed data, from Unix

$gzrecover compressed_file.gz
$ls compressed_file*
compressed_file.gz compressed_file.recovered

ssh tunnels set up and port forwarding

SSH tunnels allow you to forward a local TCP port to a remote machine and vice versa. The tunnel option is available in many ssh clients. I will give the example here on how to create SSH tunnels with putty and the openssh-client.
I will consider in the below that we want to access the SERVER on port 80 (http server).

Scenario 1. SSH tunnel setup with local port forwarding.


The SSH tunnel is shown with the red arrow. In order to access the SERVER through the ssh tunnel the connection will have to be made on the CLIENT's local forwarded port (2000 in the example). The traffic between the CLIENT and SSH-HELPER is encrypted by ssh, the traffic between the SSH-HELPER and the SERVER is not encrypted.

SSH tunnel  is set up on the CLIENT:
openssh-client:

ssh -L *:2000:server:80 ssh-helper

The '*' before the local port to be forwarded 2000 denotes that the port 2000 should be listening on all available interfaces on the client. This goes according to the openssh-client configuration.
putty:

The tunnel configuration is done under Connection - SSH - Tunnels. Source port is the local port, destination is where the connection will be forwarded after exiting the SSH tunnel.
After you specify source port and destination, you need to click "Add" for the configuration to take effect.
If you want to access the remote server from other hosts, make sure you check the box  "Local ports accept connections from other hosts", otherwise the port 2000 will be opened only for the loopback address (127.0.0.1)

Linux gnome add menu and desktop entry for applications


Users can create shortcuts for an application to appear in menus, desktop,  etc. by creating a .desktop file. This desktop file contains a listings of configuration for the application. In order for your desktop environment to "see" this file, this .desktop file will have to be placed either in /usr/share/applications - for system wide applications - or in ~/.local/share/applications - if the application should be available for a single user

Once the file is placed in this location the desktop uses this file to:


  • put the application in the Main Menu
  • list the application in the Run Application... dialog
  • create appropriate launchers in the menu or on the desktop.
  • associate the name and description of the application.
  • use the appropriate icon.
  • recognize the MIME types it supports for opening files.
Here's an example of a desktop file I have created for tinyCA application. I am running Debian Jessie and this application does not come with a any menu entries or desktop shortcut.

$ cat ~/.local/share/applications/tinyca2.desktop

[Desktop Entry]
Version=1.0
Type=Application
Name=TinyCA Certificate Authority
NoDisplay=false
Categories=Network;
Icon=security-low
Exec=/usr/bin/tinyca2
Terminal=false
Comment=TinyCA2 certificate authority
The entries one by one:

[Desktop Entry] - identifies the group name to which the desktop entry belongs. A group is name is enclosed in [ ] and there can be more than one group in a desktop file. [Desktop Entry] group is required by the basic desktop file entry
Version - version of the desktop entry specification. This field is not required