Xenserver: VDI löschen geht nicht – was tun?

Moin,

heute widmen wir uns eines kleinen Problems, daß auftreten kann, wenn beim Xenserver was richtig schlief läuft:

Beim Transfer einer VM von einem Server zum Anderen ( Stichwort: vm-import ) brach der Transfer zusammen und die importierte VM war defekt. Zu dem Zeitpunkt lies sich weder der Import abbrechen, noch störte das den zweiten Versuch. Erst beim Aufräumen der VM und Festplatten, die beim Import automatisch angelegt werden, kam es zum Problem:

Error: „This Operation Cannot be Performed Because a VDI is in Use by Some Other Operation“

Ja, ok. Und nu? Die zu löschende VM ( vm-destroy ) lies sich noch löschen, aber die daran angehängten Festplatten ( VDI ) nicht mehr. Diese wurden noch vom hängenden Import Prozess blockiert, der an der Dom0 hängt.

Hinweis: Die UUID hier sind die von meinem Server, Ihr habt andere! Die Befehle einfach so in die Konsole hauen, wird schlimmstenfalls Sachen löschen, die Ihr nicht löschen wolltet oder es passiert gar nichts 😀

Da muß man jetzt die Zähne zusammenbeißen und ein paar unfreundliche Anweisungen manuell in die Konsole hauen:

1. Damit wird der hängende Importtask endgültig terminiert:

xe-toolstack-restart

Für sich betrachtet ist der Befehl allerdings harmlos, damit geht noch nichts kaputt 😉

2. Damit sucht man sich die UUID der Festplatte raus, die man löschen will.

xe vdi-list

3. Jetzt müssen wir die VBD ( Virtual Block Device ) zu der VDI finden:

xe vbd-list vdi-uuid=bc83886b-5723-4dfe-9d5b-feebb2917d0f

Da kommt in etwa sowas raus:

uuid ( RO) : d16248e4-2c24-fa3a-1364-dcb43f5f6858
vm-uuid ( RO): 253c1fde-78d4-3719-ede6-8d0bd223b873
vm-name-label ( RO): Control domain on host: xen1
vdi-uuid ( RO): bc83886b-5723-4dfe-9d5b-feebb2917d0f
empty ( RO): false

4. Jetzt die Augen zu und durch: die VBD abziehen und löschen

xe vbd-unplug uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858
xe vbd-destroy uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858

5. und jetzt weg mit der VDI:

xe vdi-destory uuid=611441f9-20c7-6775-716a-37c78b6d672e

6. Jetzt empfehle ich noch das Storage Repository ( SR ) neu zu scannen:

xe sr-list
xe sr-scan uuid=655e2297-b012-d722-1c5f-c2814226a942

Damit wird die Liste der virtuellen Festplatten aktualisiert.

Netflix, Firefox und die 1080p – Teil 3

Endlich! Das aktuelle Firefoxproblem mit der 1080p Wiedergabe von Netflix ist gelöst.

Nachdem im Truedread Build die nötigen Anpassungen bereits vor einigen Tagen gemacht wurden, konnte endlich der Pull-Request bei Vladikoffs FireFox Version eingebaut werden.

Netflix, Firefox und die 1080p

Nun müßte man das nur noch eingebaut bekommen und da haperts gerade! Es ist etwas Handarbeit nötig um das im Firefox zu installieren. Ich habe für Euch aus den Sourcen einen AddOn-Build gebaut. Damit Firefox das unsignierte Addon schluckt, muß zuerst die Signaturprüfung abgeschaltet werden.

Dazu gebt Ihr in die Addresszeile vom Firefox „about:config“ ein und sucht nach „xpinstall.signatures.required“ und ändert es auf „false“ ( einfach „true“ Doppelklicken ).

Danach könnt Ihr dann netflix_1080p-1.9.xpi ohne Probleme installieren und habt wieder 1080p Wiedergabe im Firefox. Das File heißt noch 1.9 um es mit dem aktuellen Masterstand in Übereinstimmung zu halten, aber vermutlich wird auch Vladikoff auffallen, daß er vergessen hat die Versionnummer anzuheben 🙂

Ich vermute mal, daß es in den nächsten Tagen auch einen signierten Build geben wird. Allerdings muß man dazu bei Mozilla im DevNetzwerk angemeldet sein und da habe ich keine Lust zu 🙂

CoronaChroniken: Schulen sind keine „Todeslager“

Lieber Kasernierte,

eigentlich wollte ich heute nichts zu Corona posten, nachdem gestern der Nichteffekt der Masken publiziert wurde. Allerdings traf diese Schlagzeile einen Nerv:

Schlagzeile eines Newsportals: Todeslager für KinderCoronaChroniken: Schulen sind keine „Todeslager“

Schulen sind natürlich keine Todeslager für Kinder, aber was war da genau passiert?

Kurze Zusammenfassung:

England – Bei einer fünfjährigen wurde eine Covid-19-Infektion festgestellt und auskuriert. Nach 6 Wochen entwickelte das Kind das Kawaski-Syndrom. Der Artikel gibt eine Überlebenschance von 20% an. Die Eltern „warnen“ jetzt davor, daß Schulen „Todeslager für Kinder“ wären.

So sehr ich die Eltern verstehen kann, die Angst um Ihr Kind haben, aber das ist komplett übertriebene Panikmache vom feinsten. Das Kind hatte den Covid-19 Infekt gut überstanden und sich, vielleicht sogar ausgelöst durch den Covid-19-Virus, das Kawasaki-Syndrom eingehandelt.

Jetzt muß man über Kawasaki wissen, daß es eine sehr seltene Erkrankung bei Kindern ist, man sprach bislang von 9 Fällen auf 100.000 Kinder pro Jahr in Deutschland. Covid-19 scheint das vermehrt auszulösen, es kann aber auch jeder andere Virus sein. Die Ursachen für Kawasaki werden in einem nicht ausgereiften Immunsystem vermutet.

Nur 2-6 von 100 behandelten Kindern, also weniger als ein Kind auf 100.000 Kinder, entwickelt ein Aneurysma, bei dem die Gefahr besteht, daß es platzt und der Patient verstirbt. Aufgrund dieser geringen Rate an schweren Verläufen ist es definitiv falsch von einer Schule als „Todesfalle für Kinder“  zu sprechen. Medien, die das auch noch so propagieren, handeln verantwortungslos.

Wo wir bei „verantwortungslos“ los sind…

Alle EU Länder sind auf dem Weg zur oder schon über die Sterbenormalitätsrate hinaus, bis auf Großbritanien:

Die Grafik stammt mal wieder von EuroMOMO.eu

Was die da auf der Insel machen, scheint alles in den Schatten zu stellen, was man bei Gesundheitssystemen sonst so falsch machen kann. Selbst Italien ist bei der Normalität angelangt und die Franzosen performen quasi unter dem Normal, d.b. da sterben gerade weniger Menschen als sonst üblich:

Es handelt sich bei den Grafiken um die Darstellung zur 19. Woche, also brandaktuell und auch wieder von EuroMOMO.eu .

Wenn man so sieht, wie sich die anderen betroffenen Länder schlagen, muß man sich wirklich fragen, was genau machen die Briten da falsch? Genau wie immer noch nicht klar ist, was die da in Bergamo so besonderes hatten, als alle anderen.