Markus Bäker

Kann mir einer das mal erklären? Löscht man in Hyper-V eine VM, die Snapshots hat, dann werden erst alle Snapshots gelöscht, also in das Hauptfile zurückgeschrieben und dann die entsprechende Disk. Was für einen Sinn macht das?

Besonders extrem wird es, wenn man ein Storage Migration mit SCVMM (System Center Virtual Machine Manager 2012) macht. Dabei wird eine neue VM angelegt, die Disks kopiert und dann die alte VM mit den Disks gelöscht. Was dann bei einer VM mit Snapshots passiert kann man sich denken:

Ansicht des Jobs im SCVMM 2012:

Wie man sieht wurden die Disks innerhalb 3 Minuten kopiert und jetzt (ca. 14:05) hängt er immer noch beim Entfernen der VM.

In der Hyper-V Konsole sieht es zu dem Zeitpunkt so aus:

Destroying ist bei 25%

Ich kann mir den Sinn davon nicht erklären. Vielleicht irgendein anderer hier??

If you want to know if it is supported to run the SQL Server in a virtualized environment than this is the right article for you:

http://support.microsoft.com/kb/956893/en-us

Summaries:

1. SQL 2005 or higher is supported on Hyper-V or a hypervisor validated in the SVVP program
2. Snapshots of the VM are NOT supported.
3. Hyper-V Dynamic Memory is supported but only useful with SQL Server version Enterprise and Datacenter

Normaly you can only import a Virtual Machine (VM) into Hyper-V if you have exported it. If you lose your Hyper-V settings or have to import it into a new Hyper-V Server in case of a desaster recovery than you can use the steps descripted in this (and other) blog post: http://blogs.msdn.com/b/robertvi/archive/2008/12/19/howto-manually-add-a-vm-configuration-to-hyper-v.aspx

The problem is that you have to handle many long pathes and cryptical GUIDs. I had to do that for a bunch of different VMs and being chronical lacy I created three batch files for it:

1. importVM.cmd “GUID” “Path to Virtual Machine” creates the link and corrects the permissions on the link and the vm folder
2. importSnapshot.cmd “SnapshotGuid” “VMGuid” “Path to Snapshot” creates the snapshot link and the right permission.

Not very impressiv? Well, the third batch files combines this two scripts:

1. addMachine.cmd: Takes the basis path (the path where the sub-folder Virtual Machine, Snapshots exists) and extracts the VM-GUID, all Snapshots-GUIDs and the other pathes to automaticly create the links and permissions.

So with one simple command (addMachine.cmd C:\ClusterStorage\Volume4\VM1) you can import the complete VM.

— addMachine.cmd ——

Read more…

Wenn man am PC ein so ungeduldiger Mensch wie ich ist, dann möchte man bei einer Storage Migration mit dem SCVMM irgendwann mehr sehen, als nur die (bereits relativ detaillierte) Statusanzeige des Jobs in der System Center Virtual Machine Manager (SCVMM)  Konsole.

Der längste Teil des Verschiebens ist im allgemeinen das Kopieren der VHD Dateien. SCVMM verwendet dazu den Bits Agent auf dem Hyper-V Server. Das hat den Vorteil, dass dieser nur die zur Verfügung stehende Bandbreite nutzt und somit nicht den normalen Produktionsverkehr stört.

Auf dem Hyper-V Server ist mittlerweile kein Bitsadmin mehr vorhanden, um den Status dieser Jobs direkt auf der Quelle zu kontrollieren. Dafür gibt es mittlerweile ein Power Shell Modul.

Daher schnell powershell.exe auf der Kommandozeile des Hyper-V Servers 2008 R2 ausgeführt und darin ein

Import-Module BitsTransfer

gestartet, um das entsprechende Bits PS-Modul zu importieren.

Danach kann man sich mittels

Get-BitsTransfer -AllUsers | where {$_.JobState -eq ‘Transferring’} | fl

den Status alle gerade noch laufenden Jobs anzeigen lassen. SCVMM startet bei mehreren Platten bzw. Snapshots mehrere Transferjobs parallel. Daher sind auch bei nur einem Job mehrere Bits-Transfers sichtbar.

Heute ist die Beta zur Version 3.2 von VirtualBox im Forum publiziert worden. Unterstütz wird jetzt z.B. ein Memory Balloning, dass sogar erst Hyper-V in irgendeiner Form erst mit Windows 2008 R2 SP1 erhalten wird.

Hier die Liste der weiteren Features:

VirtualBox Version 3.2.0 is a major update. The following major new features were added:

• Following the acquisition of Sun Microsystems by Oracle Corporation, the product is now called Oracle VM VirtualBox and all references were changed without impacting compatibility.
• Experimental support for Mac OS X guests
• Memory ballooning to dynamically in- or decrease the amount of RAM used by a VM (64-bit hosts only) (see the manual for more information)
• CPU hot-plugging for Linux (hot-add and hot-remove) and certain Windows guests (hot-add only) (see the manual for more information)
• New Hypervisor features: with both VT-x/AMD-V on 64-bit hosts, using large pages can improve performance (see the manual for more information); also, on VT-x, unrestricted guest execution is now supported (if nested paging is enabled with VT-x, real mode and protected mode without paging code runs faster, which mainly speeds up guest OS booting)
• Support for deleting snapshots while the VM is running
• Support for multi-monitor guest setups in the GUI (see the manual for more information)
• USB tablet/keyboard emulation for improved user experience if no Guest Additions are available
• LsiLogic SAS controller emulation
• RDP video acceleration
• NAT engine configuration via API and VBoxManage
• Guest Additions: added support for executing guest applications from the host system
• OVF: enhanced OVF support with custom namespace to preserve settings that are not part of the base OVF standard

Da die Software jetzt in Oracle VM VirtualBox umbenannt wird, ist die Wahrscheinlichkeit wohl groß, dass Oracle sie auch weiterpflegen wird.

Weitere Details und der Downloadlink ist unter http://forums.virtualbox.org/viewtopic.php?t=30286 zu finden.

Gestern war es mal wieder so weit: Durch Storage VMotion wollte ich alte SAN Disks leeren. Daei blieb auf einer SAN-Disk Dateien einer VM zurück, die eindeutig schon verschoben war. In der Annahme, dass es sich dabei um Altlasten handelte, löschte ich diese spontan. Leider handelte es sich dabei um einen Clone der anderen Machine, die im Dateisystem leider den gleichen Namen behalten hat.

Die meisten Dateien waren gesperrt und konnten zum Glück nicht gelöscht werden. Was aber erst später auffiel: Es wurde erfolgreich die Description Datei der Platten gelöscht:

Nebenbei: Die virtuelle Disk bei VMWare besteht bei Standarddisks (also ohne Snapshot, keine RAW Files) aus zwei Dateien: eine Beschreibungsdatei mit Namen diskname.vmdk und den eigentlichen Daten in diskname-flat.vmdk. Die Beschreibungsdatei ist eine reine Textdatei mit Unix Zeilenumbrüchen (natürlich).

Solange die Maschine auf einem Host läuft, ist es noch kein Problem und fällt leider nicht auf, wenn die erste Datei fehlt. Sobald aber ein vMotion auf einen anderen Host stattfindet, dann tritt ein Fehler auf, die VM stürzt ab und kann nicht mehr gestartet werden. Im Storage Browser erkennt man den Fehler daran, dass bei derVMDK Datei kein passendes Icon davor steht bzw. nur die Datei mit -flat.vmdk zu sehen ist.

Noch kein Grund zur Panik: Zuerst: Sicherung erstellen. Besonders wichtig sind die Log Dateien. In diesen Dateien sind die später notwendigen Parametern enthalten, mit denen man die Description Datei vollständig wiederherstellen kann.

Dann: Der Anleitung unter http://sanbarrow.com/vmdk/extracting-vmdk-from-log.html folgen. Dabei ist es wichtig, einen Editor zu verwenden, der auch mit Unix Zeilenumbrüchen speichern kann (Wordpad kann es anzeigen, aber wandelt die Datei beim Anspeichern wieder um). Sobald man die Beschreibungsdatei wieder erstellt hat, kann man sie über den Storagebrowser wieder hochladen. Verschwindet die -flat.vmdk Datei nach einem Refresh und taucht das Icon vor der diskname.vmdk wieder auf, dann stehen die Chancen sehr gut, dass die Maschine wieder startet. (In meinem Fall war es zum Glück so…)

Bei Fragen einfach einen Kommentar anhängen.

Gerade Windows Installation für Templates werden häufig mit kleinen Platten (ich verwende 10GB für das System) installiert. Dies reicht für den Großteil der Installationen aus, wenn man versucht größere Datenmengen auf extra Disks zu legen. Trotzdem kommt es immer wieder vor, dass der Platz nicht reicht. Seit ESX 3.5 (Update 2?) kann man Disks im laufenden Betrieb vergrößern.

Windows erkennt dies auch automatisch. Leider kann Windows 2003 nur NIcht-Systemplatten mit Boardmitteln vergrößern. Bevor jetzt ein ein Neustart mit einem Festplattenpartitionierungsprogramm gemacht wird möchte ich auf ein kleines aber sehr mächtiges Tools hinweisen: DriveSnapshot (www.drivesnapshot.de): Dieser Imagebackuptool kann viel mehr als die meisten wissen.

Mit der grade einmal 150KByte ausführbaren Datei kann man auch im laufenden Betrieb die Systemplatte vergrößern. Dafür gibt es versteckte Kommandos, die man sich mit -!? anzeigen lassen kann.

In diesem Fall gibt ein snapshot -!resizepart c: die maximal mögliche Vergrößerung an. Ein snapshot -!resize c: 30000 vergrößert dann die c Partition auf 30000 MByte. Vorher wird ein Chkdisk (read only) durchgeführt, um sicherzugehen, dass der Datenträger in einem korrekten Zustand ist.

Diesen Weg habe ich bereits dutzende Male auf virtuellen Maschinen angewandt. Die Betreiber waren immer wieder begeistert, wie schnell ich die Systeme vergrößern konnte!

Merke: VMWare ESX und DriveSnapshot sind ein gutes Team