Univention Bugzilla – Bug 19120
Profil UCS Xen 64bit -> Instanz zeigt 32bit an
Last modified: 2023-06-28 10:46:15 CEST
Neue virtuelle Maschine aus dem Profil UCS 2.4 64bit Xen erzeugt. Im Einstellungsdialog wird mir angezeigt, dass es eine 32bit Applikation ist.
(In reply to comment #0) > Neue virtuelle Maschine aus dem Profil UCS 2.4 64bit Xen erzeugt. Im > Einstellungsdialog wird mir angezeigt, dass es eine 32bit Applikation ist. Xen merkt sich diese Information scheinbar nicht. Zumindest ist sie über libvirt nicht mehr abrufbar, obwohl sie beim Erzeugen angegeben wurde.
Das funktioniert bei einer vollvirtualisierten Instanz auch nicht. Wenn ich versuche innerhalb der DomU eine amd64-DVD zu starten, dann bekomme ich den Hinweis, dass die CPU i686 ist.
*** Bug 18599 has been marked as a duplicate of this bug. ***
Bug zwischen libvirt und Xen: Für 64-Bit Domains muß in Xen zwingend pae=1 gesetzt sein, da dadurch eine 32 Bit PAE Seitentabelle den gleichen Aufbau wie eine 64 Bit Seitentabelle hat (vgl. <http://en.wikipedia.org/wiki/Physical_Address_Extension#Page_table_structures>). Da libvirt kein <pae/> für 64 Bit Domains in den capabilities meldet, wird dies beim Erzeugen der Domain auch nicht gesetzt. UVMM ergänzt derzeit einfach für Xen 64 Bit Domains dieses Feature. Folgende Erklärung ging als Email an die libvrit-Mailingsliste: I tried to install "Microsoft Windows 2008 Server R2" on an Amd64 host using Xen-3.4.3. The installation aborted with the following error message: > Windows Boot Mager ... > File: \windows\system32\boot\winload.exe > Status: 0xc000035a > Info: Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode. For testing I converted the libvirt-XML file to an Xen-Xm file using "virsh domxml-to-native" and started that file with "xm create", which worked. Comparing the output of "xm list -a" of the broken libvirt- and the working xm-configuration I found several differences, especially with "pae": Using "xm create" pae is set to 1, while with libvirt pae is set to 0. After adding the /domain/featues/pae node to libvirts XML domain file, Windows installed fine. Looking at "virsh capabilities" I get the following (abbreviated) output: > <capabilities> > <guest> > <os_type>hvm</os_type> > <arch name='i686'> > <wordsize>32</wordsize> ... > </arch> > <features> > <pae/> > <nonpae/> > <acpi default='on' toggle='yes'/> > <apic default='on' toggle='yes'/> > </features> > </guest> > <guest> > <os_type>hvm</os_type> > <arch name='x86_64'> > <wordsize>64</wordsize> ... > </arch> > <features> > <acpi default='on' toggle='yes'/> > <apic default='on' toggle='yes'/> > </features> > </guest> > </capabilities> As you can see, neither "<pae/>" nor "<nopae/>" is listed for for the 64 bit Xen-Fv domain type, which makes it hard to automatically create a correct _and_ _working_ XML file for Xen-Fv-64 bit domains Looking at "/sys/hypervisor/properties/capabilities" I find the following capabilities reported by Xen > xen-3.0-x86_64 > xen-3.0-x86_32p > hvm-3.0-x86_32 > hvm-3.0-x86_32p > hvm-3.0-x86_64 There's also no "hvm-3.0-x86_64p" which makes me wonder, if "<pae/>" is the default for Xen-64 bit domains. If that is true, should libvirt add "<pae/"> by default to the capabilities report, or should libvirt silently pass "(pae 1)" when pushing the XML domain description to Xend? Lookign at <file:xen-3.4.3/tools/python/xen/xm/create.py>:210 I see that "pae" is enabled by default there, and thus gets enabled for each domain using "xm create": > gopts.var('pae', val='PAE', > fn=set_int, default=1, > use="Disable or enable PAE of HVM domain.")
Nachtrag: Ein Auslesen, ob eine Xen-Domain 32 oder 64 Bits ist, ist weiterhin NICHT möglich, von daher ist der Bug eigentlich nur halb-FIXED.
*** Bug 19249 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Nachtrag: Ein Auslesen, ob eine Xen-Domain 32 oder 64 Bits ist, ist weiterhin > NICHT möglich, von daher ist der Bug eigentlich nur halb-FIXED. Ja. grundsätzlich funktioniert jetzt die Installation von 64bit Systemen, das ging vorher nicht. Ich mache den Bug aber trotzdem wieder auf, allerdings müssen wir diesen nicht zum Release beheben.
Vielleicht sollte bei Xen-Instanzen dann immer die Architektur der physikalischen Maschine angezeigt werden? Ggf. könnten dann auch die 32bit Profile entfernt werden.
Seit dem Fix für Bug #22004 in UCS-2.4-3 wird das Architekturfeld bei Xen-Instanzen nicht länger angezeigt, von daher ist dieser Bug jetzt hinfällig. Mit späteren Xen-Versionen kann sich das allerdings auch wieder ändern.
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.