To do this from the command line: 
#echo "scsi-qlascan" > /proc/scsi// (qlogic 
driver will re-scan) 

Where can be either one : qla2100/qla2200/qla2300  
~ is the instance number of the HBA. 

Once that has been done , user then can force the scsi mid layer to do 
its own scan 
and build the device table entry for the new device: 
# echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi 
(scsi mid layer will re-scan) with "0 1 2 3" 
replaced by your "Host Channel Id Lun". The scanning has to be done in 
the above mentioned order. 

First the driver (qla2300/qla2200 driver etc) and then the Linux scsi 
mid layer. 
---schnipp--- 


You take a look into "dmesg | less" and search for the information about 
"Host Channel Id Lun", the Lun you have to know, from the Storage 
Administrator. 

echo "scsi-qlascan" > /proc/scsi/qla2200/1 
echo "scsi-qlascan" > /proc/scsi/qla2200/2 

echo "scsi add-single-device 1 0 0 6" >/proc/scsi/scsi 

After creating a new disk image in VMWare for this particular machine, it won’t be discovered until the system is rebooted. But there is a way to have the system discover the newly created drive without rebooting and disturbing any potential service availability. Isn’t that cool?

Let’s verify that the disk is in fact not being seen yet:

Verify the number of SCSI devices reported by the controller:

Where:
0:0:0:0 – 13.9 GB
0:0:1:0 – 161 GB

This is where the magic happens. If you want to have a look at what is happening behind the scenes, open another terminal session and tail the log:

Now the major player, the ‘- – -’ are wildcards indicating that the controller should scan everything it can scan:

At this point the ‘messages’ should log the following lines:

Let’s verify:

All seems good. Now it’s time to partition it, create a desired file system, mount, copy data, remount, all without anyone even noticing or suspecting anything. The only indication of any actions performed on the server will be a crap load of more disk space.

Downgrade from Fedora 11 with kernel-2.6.29.4-167.fc11.x86_64 to kernel-2.6.27.5-117.fc10.x86_64 to avoid VMware Server 2 crashes.

Since applying this fix I’ve been able to run VMware Server 2 on Fedora 11 however it was extremely unstable. The web based management would drop out all the time, consoles would close or freeze, and guest operating systems took hours to boot up or shut down. It was time to downgrade to a tested and more stable kernel (Fedora 10), and recompile vmware modules.

Here’s how it goes:
Go to http://mirror.anl.gov/pub/fedora/linux/releases/10/Everything/x86_64/os/Packages/ (or x86 equivalent if your system is 32 bit)
Download the following packages:
kernel-2.6.27.5-117.fc10.x86_64.rpm
kernel-headers-2.6.27.5-117.fc10.x86_64.rpm
kernel-devel-2.6.27.5-117.fc10.x86_64.rpm

Install them, do not upgrade!

(use the –force switch to force rpm to install those packages in presence of newer F11 versions)

Double check grub to verify if rpm updated the grub menu, it should list F10 kernel as one of the entries:

title Fedora (2.6.27.5-117.fc10.x86_64)
root (hd1,0)
kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro root=/dev/md2 rhgb quiet vga=0×318
initrd /initrd-2.6.27.5-117.fc10.x86_64.img
title Fedora (2.6.29.4-167.fc11.x86_64)
root (hd1,0)
kernel /vmlinuz-2.6.29.4-167.fc11.x86_64 ro root=/dev/md2 rhgb quiet vga=0×318
initrd /initrd-2.6.29.4-167.fc11.x86_64.img
title Other
rootnoverify (hd2,0)
chainloader +1

Next,

Once back in business, go root, and run:

Confirm all values, and enjoy stable VMware Server 2 again.

For systems running Intel chips see this post:
Blacklisting ‘kvm’ and ‘kvm_intel’ modules

To avoid having the kernel updated next time a system upgrade is run, put this into /etc/yum.conf

 The output comes in time order, latest first, each line showing the time of the reboot and the uptime from then to shutdown. Using last -x reboot shutdown to show the shutdown time, here's an illustration

shutdown system down  2.6.29.6-smp     Sun Mar  7 15:35 - 03:02  (11:27)
reboot   system boot  2.6.29.6-smp     Sun Mar  7 09:35          (05:59)

09:35 until 15:35 is 05:59.

When the uptime exceeds 24 hours it is shown as (+

shutdown system down  2.6.29.6-smp     Sun Feb 21 12:39 - 13:20  (00:40)
reboot   system boot  2.6.29.6-smp     Sat Feb 20 09:39         (1+02:59)

09:39 until 12:39 the next day is 1 day 02:59.

The time in parentheses at the end of the shutdown lines is normally the time until the next shutdown.

So far so good. The incorrect output is for the last reboot and shutdown of an old wtmp file. Here's the output of last /var/log/wtmp -x reboot shutdown; last -f /var/log/wtmp.1 -x reboot shutdown

[snip]
reboot   system boot  2.6.29.6-smp     Fri Mar 12 07:42          (01:54)
shutdown system down  2.6.29.6-smp     Fri Mar 12 01:31 - 09:37  (08:05)

wtmp begins Thu Mar 11 08:25:26 2010
[snip]
reboot   system boot  2.6.29.6-smp     Wed Mar 10 14:12         (15+01:42)
shutdown system down  2.6.29.6-smp     Wed Mar 10 12:41 - 15:54 (15+03:13)
[snip]

The boot started at "Wed Mar 10 14:12" which had an actual uptime of 1 day 11:20 is reported as 15 days 03:13 which is the time from then until the last -f /var/log/wtmp.1 -x reboot shutdown command was issued. The time from shutdown to shutdown is similarly affected.

 Simply issue the reboot or shutdown -r command:

# shutdown -r now

Linux / Unix Command: reboot  

 usage: reboot [-n] [-w] [-d] [-f] [-h] [-i]

[root]# last reboot
reboot   system boot  2.6.18-92.el5    Sun Oct 18 19:53         (12+14:58) 
reboot   system boot  2.6.18-92.el5    Sun Oct 18 19:39          (00:11)   
reboot   system boot  2.6.18-92.el5    Wed Oct 14 08:25         (4+11:11)  
reboot   system boot  2.6.18-92.el5    Tue Oct 13 19:54         (4+23:41)  
reboot   system boot  2.6.18-92.el5    Tue Oct 13 12:27          (07:25)   
reboot   system boot  2.6.18-92.el5    Mon Oct 12 17:48         (1+02:03)  
reboot   system boot  2.6.18-92.el5    Mon Oct 12 17:06          (00:40)   
 

 [root@localhost ~]# reboot  now

[root@localhost ~]# reboot 

usage: reboot [-n] [-w] [-d] [-f] [-i] [-p]

                  -n: don't sync before rebooting the system

                  -w: only write a wtmp reboot record and exit.

                  -d: don't write a wtmp record.

                  -f: force halt/reboot, don't call shutdown.

                  -p: power down the system (if possible, otherwise reboot)