lunedì 9 luglio 2012

VMware Manually Assigning a MAC Address to Virtual machine Cisco CUOM


Operations Manager supports VMware ESX 3.5, ESXi 4.x, and ESXi 5.0. Operations Manager musthave the same system resources available to it, inside the virtualization environment that it has for astandard (nonvirtual) installation.While determining the performance of Operations Manager in your virtual setup, you should be awarethat the VMware instance will use some system resources that would normally be available to OperationsManager in a standard installation. Additional requirements for running Operations Manager in avirtualization environment might vary with your environment and system load.Operations Manager can be installed on a virtual machine with dynamic MAC address for evaluation.However, you must configure the virtual machine with a static MAC address to purchase the permanentlicense for Operations Manager.

The static MAC address is required because licensing uses node-locking technology. The license file can
only be used with the static MAC address that you supply.
Note The static MAC address must be within the following range: 00:50:56:00:00:00 to 00:50:56:3F:FF:FF.
To set up a static MAC address:
Step 1 Power down the virtual machine.
Step 2 In the Inventory panel, select the virtual machine.
Step 3 Click the Summary tab and then click Edit Settings.
Step 4 In the Hardware list, select Network Adapter.
Step 5 For MAC address, select Manual.
Step 6 Change the current MAC address of the virtual machine to a static MAC address in the following range:
00:50:56:00:00:00 to 00:50:56:3F:FF:FF.
Step 7 Click OK.

Enable Automatic Start Up for Guest OS on VMware ESX


This one had me tearing my hair out. We needed to enable auto startup on some of our Virtual Machines on the VMware ESX server, but I couldn’t for the life of me work out how. After a stupid amount of Googling around, turning up nothing, I actually RTFM! Page 177-178 had the answers ;)
Here’s how to do it:
Launch the Virtual Infrastructure Client. If you don’t have it, just http:// to your VMware ESX host and grab it from the front page.
Go to the Configuration tab of your ESX Server, then click on Virtual Machine Startup/Shutdown.
By default (I’m pretty sure) automatic startup is disabled. To enable it, click on “Properties…” on the far upper right of the window.
You’ll now see this window:
Check/Tick “Allow virtual machines to start and stop automatically with the system”.
Now, this is the bit where I nearly cried…
You know you want to “enable” your Guest OSes to automatically boot, but how? I tried clicking and dragging, right clicking for a context menu to enable “Automatic start up” and gave up.
Turns out, you need to click on the Guest OS you’d like to enable, and then click “Move Up” until it sits underneath the “Automatic startup” title. Argh!
I really hope this helps someone out! :)

lunedì 2 luglio 2012

Controllo bad blocks sul disco con linux

badblocks is a Linux utility to check for bad sectors on a disk drive (A bad sector is a sector on a computer's disk drive or flash memory that cannot be used due to permanent damage or an OS inability to successfully access it.). It creates a list of these sectors that can be used with other programs, like mkfs, so that they are not used in the future and thus do not cause corruption of data. It is part of the e2fsprogs project.

It can be a good idea to periodically check for bad blocks. This is done with the badblocks command. It outputs a list of the numbers of all bad blocks it can find. This list can be fed to fsck to be recorded in the filesystem data structures so that the operating system won’t try to use the bad blocks for storing data. The following example will show how this could be done.

From the terminal, type following command:

$ sudo badblocks -v /dev/hda1 > bad-blocks
The above command will generate the file bad-blocks in the current directory from where you are running this command.

Now, you can pass this file to the fsck command to record these bad blocks
$ sudo fsck -t ext3 -l bad-blocks /dev/hda1
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Check reference counts.
Pass 5: Checking group summary information.

/dev/hda1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/hda1: 11/360 files, 63/1440 blocks
If badblocks reports a block that was already used, e2fsck will try to move the block to another place. If the block was really bad, not just marginal, the contents of the file may be corrupted.

Looks at badblocks man pages for more command line options.