commandlinefu.com is the place to record those command-line gems that you return to again and again.
Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.
If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/
You can sign-in using OpenID credentials, or register a traditional username and password.
First-time OpenID users will be automatically assigned a username which can be changed after signing in.
Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.
Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):
Subscribe to the feed for:
Create a serial console with "socket (named pipe)" of "/tmp/socket", "from:server, to:virtual machine" in vmware player, etc.. gui. Run the above command after you have booted the guest OS (which should also be configured for serial console).
Command used to know if we are working on a virtual or physical machine. This command will use the dmidecode utility to retrieve hardware information of your computer via the BIOS. Run this command as root or with sudo.
This command will shutdown all VMs on an VMWare ESX host. First it tries to gracefully shutdown the VM. If that fails it will hard shutdown and the power off.
So your boss wants to know how much memory has been assigned to each virtual machine running on your server... here's how to nab that information from the command line while logged in to that server
This is based on the Windows Version of VirtualBox.
From the /? ...
VBoxManage clonehd |
From the online help..
This command duplicates a registered virtual hard disk image to a new image file with a new unique identifier (UUID). The new image can be transferred to another host system or imported into VirtualBox again using the Virtual Media Manager; see the section called ?The Virtual Media Manager? and the section called ?Cloning disk images?. The syntax is as follows:
VBoxManage clonehd |
where the parameters mean:
Allow to choose a file format for the output file different from the file format of the input file.
Allow to choose a file format variant for the output file. It is a comma-separated list of variant flags. Not all combinations are supported, and specifying inconsistent flags will result in an error message.
Only honored if --remember is also specified. Defines what kind of hard disk type this image should be.
Keep the destination image registered after it was successfully written.
To monitor .vmdk files during snapshot deletion (commit) on ESX only (ESXi doesn't have the watch command):
1. Navigate to the VM directory containing .vmdk files.
# watch "ls -tough --full-time *.vmdk"
-t sorts by modification time
-o do not list group information (to narrow the output)
-u sorts by access time
-g only here for the purpose to easily remember the created mnemonic word 'tough'
-h prints sizes in human readable format (e.g., 1K 234M 2G)
--full-time sets the time style to full-iso and does not list user information (to narrow the output)
optionally useful parameters to the watch command:
-d highlight changes between updates
-n seconds to wait between updates (default is 2)
-t turn off printing the header
Converts a .vdi file to a .vmdk file for use in a vmware virtual machine. The benefit: using this method actually works. There are others out there that claim to give you a working .vmdk by simply using the qemu-img command alone. Doing that only results in pain for you because the .vmdk file will be created with no errors, but it won't boot either.
Be advised that these conversions are very disk-intensive by nature; you are probably dealing with disk images several gigabytes in size.
Once finished, the process of using the new .vmdk file is left as an exercise to the reader.