Univention Bugzilla – Bug 22714
Freien Festplattenspeicher anzeigen
Last modified: 2023-06-28 10:45:57 CEST
UVMM sollte die Möglichkeit bieten, neben der CPU-Auslastung und Hauptspeicherauslastung auch die Auslastun der (Festplatten-)Speicherbereiche (Storage Pools) anzuzeigen. Da Qcow2-Images sparse sind, führen volllaufende Festplatten dort zu problemen: Bug #22695 Das ist auch relevant beim anlegen neuer Volumes: Bug #19281
Es wäre auch gut, wenn die Hosts eine Warn-Markierung erhalten würden, wenn die Festplatte zu voll wird, wie er gerade mal wieder in der internen KVM-Umgebung passiert ist. Die Informationen sind per UVMMd bereits vorhanden, d.h. es muß "lediglich" das UMC-Modul erweitert werden. # virsh pool-info default Name: default UUID: 2551d077-5ab9-3112-2957-893d4f0d8285 Status: laufend Persistent: yes Automatischer Start: yes Kapazität: 194,56 GB Zuordnung: 180,59 GB Verfügbar: 13,96 GB # uvmm pools xen://xen5.pmhahn5.test/ DATA: [{'active': True, 'available': 90437582848, 'capacity': 317705945088, 'name': 'vg_ucs', 'path': u'/dev/vg_ucs', 'type': u'logical', 'uuid': u'14a329c4-a4ff-f7d2-5a5c-abbcb93271ec'}, {'active': True, 'available': 14992285696, 'capacity': 208904462336, 'name': 'default', 'path': u'/var/lib/libvirt/images', 'type': u'dir', 'uuid': u'2551d077-5ab9-3112-2957-893d4f0d8285'}]
Zu beachten sind die 5% für root reservierten Speicherplatz, was zu einiger Verwirrung führt (siehe auch Bug #19281 Comment 1). # python -c "import os;print 'BlockSize: %d\nTransferSize: %d\nBlocks: %d\nBlocksFree: %d\nBlocksAvail: %d\nFiles: %d\nFilesFree: %d\nFilesAvail: %d\nFlags: %x\nNameMax: %d' % tuple(os.statvfs('/'))" BlockSize: 4096 TransferSize: 4096 Blocks: 51002066 BlocksFree: 3660222 (including reserve for root) BlocksAvail: 1072526 (for non-root) Files: 12959744 FilesFree: 12532997 FilesAvail: 12532997 Flags: 1000 NameMax: 255 # su -s /bin/sh -c "df -B 4K / ; df -i /" nobody Dateisystem 4K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/mapper/vg_ucs-rootfs 51002066 47341857 1072513 98% / Dateisystem INodes IBenut. IFrei IBen% Eingehängt auf /dev/mapper/vg_ucs-rootfs 12959744 426761 12532983 4% / # su -s /bin/sh -c "df -B 4K / ; df -i /" root Dateisystem 4K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/mapper/vg_ucs-rootfs 51002066 47341857 1072513 98% / Dateisystem INodes IBenut. IFrei IBen% Eingehängt auf /dev/mapper/vg_ucs-rootfs 12959744 426761 12532983 4% / # tune2fs -l /dev/mapper/vg_ucs-rootfs | grep Reserve Reserved block count: 2587696 Reserved GDT blocks: 1011 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root)
Eventuell kann man auch anzeigen wie viel Speicher durch sparse-Dateien "reserviert" ist - also wie viel würde es belegen wenn alle sparse-Dateien voll beschrieben werden.
(In reply to comment #3) > Eventuell kann man auch anzeigen wie viel Speicher durch sparse-Dateien > "reserviert" ist - also wie viel würde es belegen wenn alle sparse-Dateien voll > beschrieben werden. Die Antwort ist einfach: ∞ (U+221E) Da Qcow2-Dateien "beliebig viele" Snapshots enthalten können, können diese Dateien auch beliebig groß werden. In abgeschwächter Form (Snapshots werden einfach ignoriert) finde ich die Idee aber gut. Siehe dazu auch die Ausgabe von "virsh vol-list --details default", wo neben der aktuellen Größe auch die reservierte Größe angezeigt wird. Siehe <http://libvirt.org/html/libvirt-libvirt.html#virStorageVolInfo> #!/usr/bin/python import libvirt c = libvirt.open('xen+unix:///') p = c.storagePoolLookupByName('default') for n in p.listVolumes(): v = p.storageVolLookupByName(n) print "Type=%s\tMax=%11d\tCurr=%11d\t%s" % (tuple(v.info()) + (v.name(),))
*** Bug 25668 has been marked as a duplicate of this bug. ***
*** Bug 22695 has been marked as a duplicate of this bug. ***
Bug #19281: Zumindest beim Anlegen wird der freie Platz im Storage-Pool jetzt angezeigt. Trotzdem fehlt noch eine Übersicht über alle Storage-Pools des Hosts; siehe dazu die RRD-Lösung an Bug #15757.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.