The Acumen IT Support blog provides you with helpful articles about Microsoft Hyper V virtualization.
Several web sites provide good overviews.
Official Microsoft Hyper-V Overview
Failover Clustering
If you use Windows Failover Clustering and use a File Share Witness as your quorum configuration, you might have a situation in which you have removed your server that had contained the file share without first removing it from the cluster. EDIT: If you haven’t destroyed your File Share, just bring it back online. In this case you find out two things: your cluster has lost its failover protection, and you can’t easily remove the failed file share witness (FSW). EDIT: You don’t lose failover protection, but you may have problems if you need to restart the cluster. See the comments below and the Microsoft link to Quorum Configurations.
When you add a new file share witness using the Quorum Configuration Wizard, the new FSW is visible. However, it is not active and your cluster will still fail if one node is turned off. The graphical interface has no way to delete the failed file share witness. Further, the “recommended” method of removing it (using the cluster.exe resource /delete command) does not work. This happens because the Failover Cluster will say that the resource cannot be deleted because it is a “core resource”.
Run the Quorum Configuration Wizard and temporarily change the mode from Node and File Share Majority to Node Majority. There is no danger in doing this. It will not affect your running cluster, and it only takes a few seconds. After you make the change, you will see that the failed File Share Witness is gone from the cluster. Make sure you already have a new File Share to use, and then run the Quorum Configuration Wizard again and choose Node and File Share Majority, selecting a new file share as the witness.
See our Microsoft Failover Cluster and Hyper-V pages for more information!
For additional help, contact Microsoft Support by clicking the link below:
HOWTO: Upgrading the CentOS kernel for a Hyper-V virtual machine with Linux Integration Components.
A kernel upgrade will cause a kernel panic. These instructions prevent the boot crash.
Upgrade the kernel:
#yum upgrade
If you boot with this, you will get the kernel panic. Don’t worry. Just press space at boot time and boot from your old kernel. Write down your new kernel number, such as 2.6.18-274.17.1.el5
Compile the Linux IC for your new kernel. You can use the latest IC at this time is v3.2:
mkdir /opt/linux_ic_rtm
cp -r /media/CDROM/* /opt/linux_ic_rtm
cd /opt/linux_ic_rtm
grep -ilR uname * | xargs sed -i 's/uname -r/echo "2.6.18-274.17.1.el5"/g'
make && make install
reboot
You can now let grub boot to your default kernel without a kernel panic.
For general IT service support, please visit us at: Acumen IT Support.
For Hyper-V consulting services, please visit us at: Hyper-V Support.
See our Virtual Private Server Hosting Pages for more information!