Bug 20043 - UCS DVS: Unterverzeichnisse im Storage Pool vermeiden
Summary: UCS DVS: Unterverzeichnisse im Storage Pool vermeiden
Status: CLOSED FIXED
Alias: None
Product: UCS
Classification: Unclassified
Component: OpenDVDI
Version: UCS 2.4
Hardware: Other Linux
: P5 normal
Target Milestone: OpenDVDI MS2
Assignee: Philipp Hahn
QA Contact: rsagner
URL:
Keywords:
Depends on:
Blocks: 19948
  Show dependency treegraph
 
Reported: 2010-09-20 10:21 CEST by Arvid Requate
Modified: 2023-03-25 06:51 CET (History)
4 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 Arvid Requate univentionstaff 2010-09-20 10:21:31 CEST
Da libvirt Probleme mit Unterverzeichnissen im Storage Pool hat, sollten die DVS-Images statt unter /var/lib/libvirt/images/"$template - $user"/ direkt unter /var/lib/libvirt/images/ abgelegt werden.
 

+++ This bug was initially created as a clone of Bug #19342 +++

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 Stefan Gohmann univentionstaff 2010-09-20 10:24:40 CEST
Das gilt auch für das Template.
Comment 2 Arvid Requate univentionstaff 2010-09-28 15:57:15 CEST
Dadurch wird dann der aktuelle Ansatz für copy-on-write Images (Bug 18765 und Bug 19755) nicht mehr funktionieren.
Comment 3 Philipp Hahn univentionstaff 2010-09-28 20:21:23 CEST
(In reply to comment #2)
> Dadurch wird dann der aktuelle Ansatz für copy-on-write Images (Bug 18765 und
> Bug 19755) nicht mehr funktionieren.

Wenn eine CoW-Instanz gerade nicht läuft, zeigt der Symlink auf das /dev/mapper/*-Device ist leere, was libvirt überhaupt nicht mag: Der Storage-Pool kann anschließend nicht mehr gestartet werden.
Ursache dafür ist, daß sich der Symlink nicht öffnen lässt und deshalb die Validierung des Pools abbricht:

libvirt/src/storage/storage_backend_fs.c#virStorageBackendProbeTarget()
    if ((ret = virStorageBackendVolOpenCheckMode(target->path,
                                                 (VIR_STORAGE_VOL_OPEN_DEFAULT & ~VIR_STORAGE_VOL_OPEN_ERROR))) < 0)
        return ret; /* Take care to propagate ret, it is not always -1 */

libvirt/src/storage/storage_backend.c#virStorageBackendVolOpenCheckMode()
    if ((fd = open(path, O_RDONLY|O_NONBLOCK|O_NOCTTY)) < 0) {
        virReportSystemError(errno,
                             _("cannot open volume '%s'"),
                             path);
        return -1;
    }

Durch die trickreiche Verwendung der Symlinks durch univention-cow ist es deshalb unmöglich, daß derzeit sauber mit UVMM zu verschmelzen. Auf jeden Fall wird so jeder Versuch scheitern, eine Instanz inklusive all seiner (CoW-)Images zu löschen.
Comment 4 Stefan Gohmann univentionstaff 2010-09-28 20:50:26 CEST
Hier sollten wir Xen4 und blktap2 nochmal prüfen.
Comment 5 Philipp Hahn univentionstaff 2010-10-08 11:07:54 CEST
univention-dvs-node/univention-dvs-create-desktop erzeugt jetzt keine Unterverzeichnisse mehr, sondern legt für jedes Image einer Instanz eine Datei "${dvs/desktop/directory}/${user} ${template_name}_${nr}" an.

CoW funktioniert derzeit nicht.
Comment 6 rsagner univentionstaff 2010-11-24 10:45:55 CET
Das beschriebene Problem ist gelöst