Univention Bugzilla – Bug 19574
UVMM - Lokales DVD / CDROM Laufwerk einbinden
Last modified: 2013-03-22 18:10:08 CET
Es sollte die Möglichkeit geben das lokale DVD / CDROM Laufwerk einzubinden.
auch nachgefragt an Ticket#2010120610000956
Es können jetzt Laufwerke angelegt werden, die mit einem lokalen Gerät verbunden sind. Das gilt für Festplatten und CDROM Laufwerke, da der Aufwand nicht größer war das auch für beide zu unterstützen. Wenn das nicht bleiben soll, dann den Bug wieder öffnen.
Derzeit wird nach dem Gerätedateinamen gefragt und /dev/cdrom vorgeschlagen. Sollten wir vielleicht das /dev/ weglassen und nur nach dem Namen des Blockdevice fragen? Im Code müsste dann einfach /dev/ vorangestellt werden, wenn es nicht enthalten ist. Ich glaube es ist besser, wenn die Leute nur cdrom oder sr0 schreiben müssen, anstatt /dev/cdrom oder /dev/sr0. Die Liste vorzugeben dürfte schwierig sein, da libvirt diese meines Wissens nicht kennt. Hier würde nur der Umweg über das LDAP gehen. Wenn ein Blockdevice gefunden wird, dann könnte dies direkt im LDAP am Node gespeichert werden.
*** Bug 21866 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Derzeit wird nach dem Gerätedateinamen gefragt und /dev/cdrom vorgeschlagen. > Sollten wir vielleicht das /dev/ weglassen und nur nach dem Namen des > Blockdevice fragen? > Im Code müsste dann einfach /dev/ vorangestellt werden, wenn es nicht enthalten > ist. > > Ich glaube es ist besser, wenn die Leute nur cdrom oder sr0 schreiben müssen, > anstatt /dev/cdrom oder /dev/sr0. Wie mit Stefan abgesprochen, ist diese Variante jetzt umgesetzt.
Ich habe mit einem aktuellen 2.4-2 unter KVM und Xen eine VM angelegt. Unter KVM bekomme ich trotz eingelegter DVD nur die Fehlermeldung vom SeaBIOS Could not read from CDROM (code 0001) Unter Xen bekomme ich nach dem Start der Maschine in UVMM folgende Fehlermeldung: Error managing domain "fda00f63-98c0-460d-ea01-143f1f64463b": POST operation failed: xend_post: error from xen daemon: (xend.err "Boot loader didn't return any data!") Der Xen-Server läuft auf 192.168.0.116, der KVM-Server unter 192.168.0.118 Die Eingabemaske müsste auch noch besser erklärt werden, z.Zt. steht da z.B. ---------------------------------------- Laufwerk zu ucs24-06 hinzufügen Um das Laufwerk an ein lokales Gerät zu binden, muss der Dateiname der zugehörigen Gerätedatei angeben werden. Gerätedateiname [ cdrom ] ---------------------------------------- Es ist irreführend, dass in der Eingabemaske cdrom vorausgewählt ist, auch wenn oben vom Gerätenamen die Rede ist. Wenn man nicht weiss, dass UVMM das intern umschreibt würde man eher "/dev" manuell davor setzen. Vorschlag: Um das DVD/CD-ROM-Laufwerk der Instanz an ein Laufwerk des Virtualisierungs-Servers zu binden, muss der Name der Gerätedatei im Verzeichnis /dev angegeben werden. In den meisten Fällen kann die Vorgabe cdrom übernommen werden.
Das Problem scheint zu sein, dass CDROM-Laufwereke, die eine Block-Device nutzen, nicht para-virtualisiert eingebunden werden können. libvirt akzeptiert die Konfiguration, aber der Zugriff funktioniert nicht mehr. Folgendes funktioniert bei mir: <disk type='block' device='cdrom'> <driver name='qemu' type='raw'/> <source dev='/dev/cdrom'/> <target dev='hda' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' unit='0'/> Dies geht nicht: <disk type='block' device='cdrom'> <driver name='qemu' type='raw'/> <source dev='/dev/cdrom'/> <target dev='vdb' bus='virtio'/> <readonly/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk>
Es gibt einige Einschränkungen: KVM: über IDE Xen-PV: nur als PV Xen-HVM: über IDE CDROMs, die als Block Devices eingebunden werden können nicht bearbeitet werden
Die Änderung svn23086 hat jetzt die Verwendung von LVM als Storage-Pool kaputt gemacht: Dortige Storage-Volumes heißen z.B. /dev/vg_ucs/volume1. Durch die Verwendung von basename() wird daraus nur noch "volume1", was durch das davorhängen von nur "/dev/" nicht wieder das Original ergibt. Siehe außerdem Bug #21979.
*** Bug 21979 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Die Änderung svn23086 hat jetzt die Verwendung von LVM als Storage-Pool kaputt > gemacht: Dortige Storage-Volumes heißen z.B. /dev/vg_ucs/volume1. Durch die > Verwendung von basename() wird daraus nur noch "volume1", was durch das > davorhängen von nur "/dev/" nicht wieder das Original ergibt. > Siehe außerdem Bug #21979. Die Änderung habe ich wieder rückgängig gemacht.
Neuer Traceback nach der Verwendung von LVM-Volumes: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/__init__.py", line 160, in execute func( object ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/__init__.py", line 1196, in uvmm_domain_create result = self.domain_wizard.action( object, ( node_uri, node_info ) ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/wizards.py", line 565, in action return umcd.IWizard.action( self, object ) File "/usr/lib/python2.4/site-packages/univention/management/console/dialog/wizard.py", line 199, in action return self.actions[ action ]( object ) File "/usr/lib/python2.4/site-packages/univention/management/console/handlers/uvmm/wizards.py", line 813, in new_drive self.drive_wizard.blacklist = [os.path.basename(drive.source) for drive in self.drives] File "/usr/lib/python2.4/posixpath.py", line 112, in basename return split(p)[1] File "/usr/lib/python2.4/posixpath.py", line 77, in split i = p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute 'rfind'
Der DriveWizard wurde entrümpelt: Es gibt jetzt nur noch ein options-Attribut, in dem für die 3 Fälle (neues Image, existierendes Image, lokales Gerät) der Name des Images (relativ zum Pool) oder der absolute Pfadname des /dev/-Geräts liegt. Dabei wurde an etlichen Stellen auch noch die Behandlung von Storage-Pools korrigiert, die statt Dateien direkt Block-Devices liefert (lvm, iSCSI): Dort wird jetzt auch die Größe des Storage-Volumes und der Pfad innerhalb des Volumes angezeigt. svn23173, univention-virtual-machine-manager-daemon_0.9.203-1.212.201103251055 Keine weitere Änderung am ChangeLog-Eintrag gemacht.
Ich habe unter Xen und KVM jeweils eine UCS und WinXP-VM angelegt und dabei eine UCS- bzw. Windows-CD über /dev/cdrom eingebunden. In allen Fällen startete der Installer korrekt.
UCS 2.4-2 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".
(In reply to comment #7) > Das Problem scheint zu sein, dass CDROM-Laufwereke, die eine Block-Device > nutzen, nicht para-virtualisiert eingebunden werden können. libvirt akzeptiert > die Konfiguration, aber der Zugriff funktioniert nicht mehr. (In reply to comment #8) > Es gibt einige Einschränkungen: > > KVM: über IDE > Xen-PV: nur als PV > Xen-HVM: über IDE > > CDROMs, die als Block Devices eingebunden werden können nicht bearbeitet werden Diese Einschränkungen scheinen nur für die Bootbarkeit zu gelten, da das von Qemu/KVM verwendete SeaBios keine Unterstützung für das Booten von VirtIO-CDROM- und -Floppy-Laufwerke besitzt; nur das Booten von VirtIO-HDs funktioniert. Das Booten per VirtIO-raw-HD und der anschließende Zugriff auf ein VirtIO-raw-CDROM aus Linux heraus funktionieren; selbst ein "eject /dev/vdb" funktioniert und wirft die physikalische CDROM aus. Von daher sollten CDROMs (und ggf. FLOPPY) per Default als IDE (bzw. bei Xen-PV als PV) eingebunden werden, aber die Option zum Wechsel auf VirtIO bestehen. Hier die Bugs bei RedHat zum Thema VirtIO & CDROM: <https://bugzilla.redhat.com/show_bug.cgi?id=517151> Hier der SeaBios-Patch für die initiale VirtIO-Unterstützung, der sehr nach Disk-only aussieht: <http://kerneltrap.org/mailarchive/linux-kvm/2010/5/10/6261873>