Bug 19342 - Unterverzeichnisse im Pool
Summary: Unterverzeichnisse im Pool
Status: CLOSED FIXED
Alias: None
Product: UCS
Classification: Unclassified
Component: Virtualization - UVMM
Version: UCS 2.4
Hardware: Other Linux
: P5 normal
Target Milestone: UCS 2.4-1
Assignee: Philipp Hahn
QA Contact: Janek Walkenhorst
URL:
Keywords:
Depends on:
Blocks: 19797
  Show dependency treegraph
 
Reported: 2010-08-10 10:29 CEST by Stefan Gohmann
Modified: 2010-12-10 16:36 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Customer ID:
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2010-08-10 10:29:03 CEST
Derzeit werden Images in Unterverzeichnissen nicht angezeigt. Schön wäre es, wenn sämtliche Image Dateien angezeigt werden, inkl. Pfad, wodurch eine bessere Strukturierung möglich ist.
Comment 1 Andreas Büsching univentionstaff 2010-08-11 09:31:31 CEST
Das wird momentan nicht von dem FS/Dir Storage Backend in libvirt (0.8.3) unterstützt:

/**
 * Iterate over the pool's directory and enumerate all disk images
 * within it. This is non-recursive.
 */
static int
virStorageBackendFileSystemRefresh(virConnectPtr conn ATTRIBUTE_UNUSED,
                                   virStoragePoolObjPtr pool)


Das Verzeichnis wird mit readdir ausgelesen
Comment 2 Philipp Hahn univentionstaff 2010-09-10 16:46:34 CEST
Das wird gerade bei DVS zum Problem: Die Instanzen sind komplette Verzeichnisse, in denen die Images liegen. Diese werden nach $dvs/desktop/directory=/var/lib/libvirt/images/ kopiert. Beim Anlegen der Instanz überprüft der UVMM, ob das Image bereits existiert. Vorher lagen diese außerhalb jedes Pools unter /var/lib/xen/, jetzt liegen sie in einem Unterverzeichnisses des default-Pools und werden nicht mehr durch conn.storageVolLookupByPath() gefunden. Erst später beim Anlegen tritt dann ein Fehler auf und es wird eine Exception libvirtError().get_error_code() == libvirt.VIR_ERR_NO_STORAGE_VOL geworfen.

In svn:component/uvmm/univention-virtual-machine-manager-daemon r19644 existiert zumindest für dieses Problem jetzt ein Work-Around.
Comment 3 Stefan Gohmann univentionstaff 2010-09-20 09:32:54 CEST
(In reply to comment #2)
> Das wird gerade bei DVS zum Problem: Die Instanzen sind komplette
> Verzeichnisse, in denen die Images liegen. Diese werden nach

Müssen die Instanzen denn in eigenen Verzeichnissen liegen?
Comment 4 Philipp Hahn univentionstaff 2010-09-20 10:03:35 CEST
(In reply to comment #3)
> (In reply to comment #2)
> > Das wird gerade bei DVS zum Problem: Die Instanzen sind komplette
> > Verzeichnisse, in denen die Images liegen. Diese werden nach
> 
> Müssen die Instanzen denn in eigenen Verzeichnissen liegen?

Derzeit wird pro DVS-Instanz einfach das Template-Verzeichnis kopiert: Darin können prinzipiell auch mehrere Festplattenimages pro Instanz vorhanden sein. Auch bei CoW werden pro Image 3 Verzeichniseinträge benötigt: 1* Diff-Datei, 1* Symlink auf DeviceMapper-Node, 1* Symlink auf original Master-Imagedatei.

Der Inhalt eines Pools wird u.a. innerhalb des UMC-Modules beim Wiederverwenden von Images angezeigt: Derzeit werden Dateien, Symlinks, Character- und  Block-Devices, aber  keine Unterverzeichnisse angezeigt.

Beim Anlegen per 'pool-create-as --name temp --type dir --target "/var/lib/libvirt/images/temp"' führen tote Symlinks zu einem Abbruch des Anlegevorgangs. Das ist damit für nicht-laufenden CoW-Instanzen Problem, da diese Verzeichnisse einen Symlink nach /dev/mapper/*  enthalten.
Comment 5 Philipp Hahn univentionstaff 2010-10-12 19:13:39 CEST
DVS nutzt jetzt eine flache Hierarchie.
Es ist fraglich, ob so eine Änderung jemals in libvirt einfließen würde. Vermutlich nicht, da für Unterverzeichnisse eine komplett neue Logik notwendig wird: Parsen von Pfaden, fallabhängig Verzeichnisse oder Dateien erstellen, leere Verzeichnisse löschen, Verzeichnisse traversieren, Symlink-Behandlung, Mount-Point Überschreitung (df ändert sich!)
Comment 6 Philipp Hahn univentionstaff 2010-11-23 10:19:57 CET
UVMM überprüft nun vor dem Anlegen eines Images, ob es unter diesem Pfad schon ein Image gibt und führt einen Refresh der Pools durch. Das ist zwar nicht mehr so relevant, weil DVS nicht länger Unterverzeichnisse nutzt, führte aber trotzdem zu einigen Problemen, wenn an UVMM vorbei Images in den Verzeichnissen abgelegt wurden.

In 2.4-1 übernommen.

svn 21108+21113, univention-virtual-machine-manager-daemon_0.11.0-1

ChangeLog:
\item Bei der Verwaltung von Images wurden einige Fehler behoben
(\ucsBug{19342}) und Vorbereitungen zur Unterstützung weiterer Image-Formate
getroffen (\ucsBug{18765}).
Comment 7 Philipp Hahn univentionstaff 2010-12-03 12:52:02 CET
Beim Anlegen von Images wird nun auch überprüft, ob ein Image zwar bereis existiert, aber derzeit von keiner VM verwendet wird.

svn21375, univention-virtual-machine-manager-daemon_0.10.11-5.113.201012031247
Comment 8 Janek Walkenhorst univentionstaff 2010-12-03 15:31:46 CET
Verified: Wird beim Erstellen neuer Images geprüft
Comment 9 Sönke Schwardt-Krummrich univentionstaff 2010-12-10 16:36:52 CET
UCS 2.4-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden:
"Clone This Bug".