tech.kaotix.dk

In our ESX environment, I extended a virtual disk from VirtualCenter and created a new partition on it using fdisk. The new partition was to be added to a Volume Group under LVM. But the OS (RHEL5 in this case) didn’t recognize the partition. “pvcreate” said it could not find the the device it was “Ignored by filtering” – As it turned out it was not so much a question of filtering as the fact that the device file was missing; /dev/sdb2 simply did not exist. I did a lot of searching and jumping through hoops for a solution that did not include a reboot (the server in question is a production server) – While there might very well be other solutions to this – the one I found turned out to be quite simple: Don’t use fdisk – use “parted” instead:

parted DEVICE
(parted) mkpart PART-TYPE START END
(parted) toggle PART-NUMBER FLAG

in my case it looked like this:

parted /dev/sdb
(parted) mkpart primary 53.7GB 107GB
(parted) toggle 2 lvm
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  53.7GB  53.7GB  primary               lvm
 2      53.7GB  107GB   53.7GB  primary               lvm

And Voila! – you’ll have a new partition AND the corresponding device file!

First of all. If you don’t know what a SMT-server is you probably don’t need to read any further.

Problem: I was deploying a number of SLES10-SP3 servers in an ESX environment by cloning from a running server – and that all went according to plan. However, when I tried to register the servers to our SMT server the first registration went fine, but the following registrations simply overwrote the previous.

Solution: Google to the rescue!! Rename “deviceid” and “secret” (you could choose to delete them instead if you’re that kind of sys admin – I’m not!) in /etc/zmd and re-run the registration process:

clientSetup4SMT.sh --host <your  SMT server>

On some of the servers I also had to run

suse_register -r

in order to restore the repository list, but on others I had no issues – well, go figure!

The following one-liner will generate a random eight character string consisting of numbers as well as upper- and  lowercase letters.

echo `< /dev/urandom tr -dc A-Za-z0-9 | head -c8`

or

tr -dc '0-9a-zA-Z' </dev/urandom |head -c8; echo

If you need a shorter or longer password you can ajust the “-c8”-value.

And yes, I know…… a password should contain special characters as well. Please feel free to add a few periods and asterisks

I found this on the net somewhere. I don’t remember where – sorry.

To add a vmdk to a virtaul RHEL5 server, you first of all need to create the vmdk (d’oh!) – I won’t go into that here. Next, on the RHEL5 server do as root:

echo "- - -" > /sys/class/scsi_host/host0/scan (the spaces between the dashed are important)

This will cause the scsi bus to be rescanned and the new disk should be found. For the devicename check “dmesg”. Now you can partition the disk, add it to LVM or whatever.

I tried to do a shutdown of a VM from VirtualCenter (vSphere client)  only to recieve an error:  “another task is already in progress”.

Looking through my event-log in VirtualCenter, I saw that an earlier task (a cloning of same VM) had failed due to a timout.

The solution seems to be to log into the ESX servers service console and stop and start the mgmt-vmware service by doing:

# service mgmt-vmware stop

wait 30 seconds or so and start the service again

# service mgmt-vmware start

It seems that the wait is important. A mere “# service mgmg-vmware restart” did not resolve the issue.

This procedure will temporarily disconnect your esx-server – and VM’s running on it – from Virtual Center but otherwise it will not disturb your operation.

Recently a VM on a ESX host (version 2.5.3) refused to power on.

From the Service Console i tried to getstate:

vmware-cmd <.vmx-file> getstate

but all I got was an error:

/usr/bin/vmware-cmd: Could not connect to VM <.vmx-file>
  (VMControl error -14: Unexpected response from vmware-authd: Error connecting to /usr/lib/vmware/bin/vmware-vmx process.)

As it turned out the problem was that an old process was still existing and it was convinced it was running the VM already, which it was not.

# grep -r ".vmx" /proc/vmware/

extract the VM’s PID from the output and

# kill -9 <PID>

# vmware-cmd <.vmx-file> getstate

should now produce a more reasonable output. If you want to power on the VM da a:

# vmware-cmd <.vmx-file> start

If you need to force a user to change password at next login, simply use:

# chage -d 0 <userid>

vmkfstools is your friend. In ESX 2.5.x you can use the switch “-P” on the “mapping”-file to show you details of the RDM.

# vmkfstools -P /vmfs/FileSystem1/somemachinesdiskfile-META.vmdk

in VI3 the switch has changed to “–queryrdm” or just “-q” for short.

# vmkfstools -q /vmfs/FileSystem1/somemachinesdiskfile.vmdk