Upgrade Microsoft Hyper-V Linux IC from 3.3 to 3.4

Recently I had to upgrade the integration components on a lot of CentOS virtual systems running on a Hyper-V failover cluster. During the upgrade procedure I faced a couple of things, which I'd like you to be aware of. The version on the guest VM is CentOS 6.3, the Hyper-V failover cluster is running under Windows Server 2008 R2 SP1 and consists of 6 nodes.

Below is the output of LVM related commands before starting the upgrade of Linux IC:

Extending a LVM partition in a Hyper-V guest VM running CentOS

Imagine a scenario like the following: you have a Hyper-V host and a CentOS 6.3 guest. The CentOS guest has Microsoft Integration Services for Linux 3.3 installed and running. A data file system on the guest is running out of the free space:

[root@myhost ~]# df -h /data/svn/

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/data-svn   99G   93G  964M  99% /data/svn

Although the partition is a part of LVM, but your entire disk is almost full. In the article I'd like to show how you can get rid of this without getting your services offline.

Symantec Backup Exec and Restore to Hyper-V Failover Cluster

Assume, that your organization uses Symantec Backup Exec 2010 to backup Hyper-V VMs. What have you to keep in mind, if you need to restore a Hyper-V VM from a backup created by Backup Exec 2010? I've written a couple of points that could be useful to think of to plan such a restore job:

• Backup Exec 2010 can restore as to the same Hyper-V failover cluster, where the VM is backed up as well to a different Hyper-V failover cluster. This method can be used to move VMs between the Hyper-V clusters, especially if the Hyper-V clusters are either not connected at all or connecvted through a WAN at a low speed.
• Backup Exec 2010 doesn't use failover cluster capabilities while restoring a Hyper-V VM and therefore restores to a single Hyper-V node in the cluster directly.
• The restored VM is not failover enabled, because it is restored only to a Hyper-V node. To make the VM failover enabled you must move the restored VM to another Hyper-V node in the failover cluster. Either you export the VM on the Hyper-V node with Hyper-V Manager and import it with Failover Cluster Manager or you can use Microsoft SCVMM to move the VM. Depending on the method of making the VM failover enabled and on the VHD size it takes either much time or a lot of time. You must take this fact into account, when you develop your backup and recovery concept.
• Make sure that you enabled the option in the restore job settings to overwrite the existing VM. If you don't enable the option and you do have a VM with the same name existing on your Hyper-V node, Backup Exec 2010 restore job fails only after the whole data is written back from the tape to the Hyper-V node and the VM is going to be registered in Hyper-V. The correction the failure and a new run of the restore job cost time.
• Pay attention to the free space of the system drive (usually C:) of the Hyper-V node, which Backup Exec chosen as target to recover to, because the standard restore path points to the system drive.
• After the restore has finished you should review the hardware settings of the restored VM, especially if you restored from one Hyper-V failover cluster to a different one. This check includes such things like network name and the VLAN id and may be RAM and CPU settings too.
• After the restored VM is up you must check the network settings inside of the VM to be sure, it has network access after the restoration. 

Massive Probleme von Novell SLES 11 SP1 VMs unter Hyper-V

Hallo,

ich würde jedem vom Einsatz von Novell SuSE Linux Enterprise Server 11 SP1 als virtuelle Maschinen unter Hyper-V abraten. Nach mehreren Monaten leidiger Erfahrungen kann ich mit Sicherheit sagen, dass die folgenden Enterprise-Feautures in SLES 11 SP1 große Probleme verursachen, für die es im Moment keine Lösung gibt:

• Wenn das Netzwerkinterface in der VM als Synthetischer Adapter (synthetic adapter) zur Verfügung steht, kommt es sehr oft zur Unterbrechung der Netzwerkanbindung. Hierbei werden keine relevanten Meldungen in der VM sowie auf dem Hyper-V-Host protokolliert. Die VM wird von jetzt auf gleich nicht mehr erreichbar im LAN. Eine kurzfristige Lösung besteht darin, den Befehl
  rcnetwork restart
  in der VM auszufühen bzw. die VM neu zu starten. 
• Wenn eine der Festplatten als SCSI-HDD zur Verfügung steht, kann es durch den Stand-By-Modus zum temporären Verlust der Partitionen führen, die auf der SCSI-Festplatte liegen. Das Phänomen tritt zu Tage, wenn die VM in den Modus "Save state" geschaltet wird. Dieser Modus wird u.a. benötigt während des Backup der ganzen VM auf der Hyper-V-Seite oder vor dem Umzug der VM auf einen anderen Hyper-V-Knoten.

Das Problem mit dem Netzwerkadapter kann man umgehen, indem die VM auf den emulierten Adapter (emulated NIC) umgestellt wird. Dieser läuft sehr stabil, allerdings ist die Performance wesentlich schlechter, es gibt außerdem vereinzelt Probleme nach dem Aufwachen aus "Save state".

Das zweite Problem ist schwerwiegender, weil IDE-Festplatten unter Hyper-V höchstens 128 Gbyte groß sein können. Größere Datenvolumen setzen also SCSI-Festplatten voraus.

Interessanterweise hatten wir keinerlei Problem beim Betrieb von SLES 11 OHNE SP1. In dem System werkelten die Linux Integration Tools v2.1 der Firma Microsoft. Seit dem SP1 für SLES 11 lassen sich die Linux Integration Tools v2.1 nicht mehr installieren: die Install-Routine läuft auf einen schwerwiegenden Fehler. Und die mitgelieferten Hyper-V Treiber sind offensichtlich die Wurzel des Übels und bereiten nur Probleme.

Symantec Backup Exec und Hyper-V Failover Cluster: Failed to log on to

Assume, you're having a Hyper-V failover cluster and, assume, you are going to create a backup job in Backup Exec 2010 server console. 


If you get the error "Failed to log on to" e.g. while trying to modify the appropriate "Selection list", you should check up, whether Backup Exec 2010 can establish a connection to each of the Hyper-V nodes. If it's working, the error could be caused by the missed DNS-entry for the Hyper-V fail-over cluster. 


In this case re-created the DNS-entry and re-try the connectivity in a couple of minutes later.