During my first two attempts to install Xen and create a Debian based DomU, I got the following error:> xl create /etc/xen/debian.cfg > Parsing config from /etc/xen/debian.cfg > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->0000000000175488 > TOTAL: 0000000000000000->000000001f800000 > ENTRY ADDRESS: 0000000000100608 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000000fb > 1GB PAGES: 0x0000000000000000 > libxl: error: libxl_dm.c:1086:libxl__spawn_local_dm: device model > /usr/lib/xen-4.2/bin/qemu-dm is not executable: No such file or directory > libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: (null): > spawn failed (rc=-3)With my first attempt, Plan A, I compiled xen-unstable and after tweaking my config file I did something to ''fix'' the error. Don''t remember exactly what I did, but I fear I just commented out the "builder" line, which makes sense. A short time later though, I did something that broke the xenstore and xenconsole daemons. In a fit of frustration,I went to Plan B. To execute Plan B, I decided to restart from scratch and use Xen 4.2 from Debian''s experimental repositories. Things went smoothly until I tried tocreate my first DomU. The same error message again. This time I went searching and found a reference <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688311> to it in Debian''s bugtracking system. Although, it did not offer a clear solution.So, I figured I''d try to install qemufrom the Debian repositories. Sadly, I got a similar error about qemu missing, though this time not "qemu-dm"... I think it was "qemu-system-i386" but I can''t recall exactly. I thought I captured the error message, but either I didn''t or I misplaced the text file.Anyway,the result was the same. Now I''m on Plan C. Whichis just revisiting PlanA. Re-installing from scratch and compiling Xen and the linux kernel from source. This time however, I plan to snapshot my Dom0''s LVafter I compile and before I install so I can easily revert to a ''clean'' system. So, I''m about to compile the latest xen-unstable per the instructions here <http://wiki.xen.org/wiki/Compiling_Xen_From_Source>. However, I''m unsure if I should build xen withqemu-upstream as mentioned on this page <http://wiki.xen.org/wiki/QEMU_Upstream>, or go with vanilla qemu-stable-1.0? Which I gather should be built during the compilation of Xen... though given the error messages, I wonder about that. Advice, please? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Xen 4.2 compiled from source should include both traditional and upstream qemu. Upstream does not have complete passthrough support, if you are doing anything of that nature best to stick to traditional. The Xen Man Pages have the most up to date configuration: http://wiki.xen.org/wiki/Xen_4.2_Man_Pages The flag to set per HVM Configuration is `device_model_version`, its values are "qemu-xen" and "qemu-xen-traditional", the traditional being the default. Key benefits are alternative BIOS, though the UEFI BIOS has to be specified to build when compiling Xen. On Fri, Dec 7, 2012 at 8:17 PM, ShadesOfGrey <shades_of_grey@earthlink.net>wrote:> During my first two attempts to install Xen and create a Debian based > DomU, I got the following error: > > xl create /etc/xen/debian.cfg > Parsing config from /etc/xen/debian.cfg > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->0000000000175488 > TOTAL: 0000000000000000->000000001f800000 > ENTRY ADDRESS: 0000000000100608 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000000fb > 1GB PAGES: 0x0000000000000000 > libxl: error: libxl_dm.c:1086:libxl__spawn_local_dm: device model > /usr/lib/xen-4.2/bin/qemu-dm is not executable: No such file or directory > libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: (null): spawn > failed (rc=-3) > > > With my first attempt, Plan A, I compiled xen-unstable and after tweaking > my config file I did something to ''fix'' the error. Don''t remember > exactly what I did, but I fear I just commented out the "builder" line, > which makes sense. A short time later though, I did something that broke > the xenstore and xenconsole daemons. In a fit of frustration, I went to Plan > B. > > To execute Plan B, I decided to restart from scratch and use Xen 4.2 from Debian''s > experimental repositories. Things went smoothly until I tried to create > my first DomU. The same error message again. This time I went searching > and found a reference<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688311>to it in Debian''s > bug tracking system. Although, it did not offer a clear solution. So, I > figured I''d try to install qemu from the Debian repositories. Sadly, I got > a similar error about qemu missing, though this time not "qemu-dm"... I > think it was "qemu-system-i386" but I can''t recall exactly. I thought I captured > the error message, but either I didn''t or I misplaced the text file. > Anyway, the result was the same. > > Now I''m on Plan C. Which is just revisiting Plan A. Re-installing from > scratch and compiling Xen and the linux kernel from source. This time > however, I plan to snapshot my Dom0''s LV after I compile and before I > install so I can easily revert to a ''clean'' system. So, I''m about to > compile the latest xen-unstable per the instructions here<http://wiki.xen.org/wiki/Compiling_Xen_From_Source>. > However, I''m unsure if I should build xen with qemu-upstream as mentioned on > this page <http://wiki.xen.org/wiki/QEMU_Upstream>, or go with vanilla > qemu-stable-1.0? Which I gather should be built during the compilation > of Xen... though given the error messages, I wonder about that. > > Advice, please? > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 12/07/2012 11:20 PM, Casey DeLorme wrote:> > Xen 4.2 compiled from source should include both traditional and > upstream qemu. > > Upstream does not have complete passthrough support, if you are doing > anything of that nature best to stick to traditional. > > The Xen Man Pages have the most up to date configuration: > http://wiki.xen.org/wiki/Xen_4.2_Man_Pages > > The flag to set per HVM Configuration is `device_model_version`, its > values are "qemu-xen" and "qemu-xen-traditional", the traditional > being the default. Key benefits are alternative BIOS, though the UEFI > BIOS has to be specified to build when compiling Xen.IIRC, I tried setting the ''device_model_version'' flag to "qemu-dm" and "qemu-xen". In both cases I got the error message I quoted. If "qemu-dm" has been deprecated, the error makes sense. If, for some reason, qemu-upstream didn''t get pulled down, the error would also make sense. I didn''t try try "qemu-xen-traditional". But that''s only because I''m pretty sure that, once the other two values failed, I checked the contents of "/usr/lib/xen-4.2/bin/" and found it had no qemu executables. Still, my recollection could be wrong. I thought I had documented most the non-trivial errors that I encountered. I have a feeling that I lost some of those I captured after reformatting my Dom0 LV. I was pretty sleep deprived after two marathon session last week. So, if I forget to backup my error logs, I could also be misremembering what the results of changing ''device_model_version'' values were. BTW, are there any significant advantages to using the OVMF UEFI firmware? I thought since my motherboard has an UEFI firmware, having qemu use an UEFI firmware might somehow be advantageous. However, the last time I tried compiling Xen with "--enable-ovmf", make bombed out with the following:> "/usr/bin/gcc" -c -x assembler -imacros > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG/AutoGen.h > -m64 --64 -melf_x86_64 -o > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/X64 > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include/X64 > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Include > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.iii > gcc: error: unrecognized command line option ''--64'' > make[7]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib'' > gcc: error: unrecognized command line option ''-melf_x86_64'' > make[7]: *** > [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj] > Error 1 > > > build.py... > : error 7000: Failed to execute command > make tbuild > [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib] > > > build.py... > : error F002: Failed to build module > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > [X64, GCC44, DEBUG] > > - Failed - > Build end time: 04:32:20, Dec.08 2012 > Build total time: 00:00:02 > > make[6]: *** [ovmf.bin] Error 1 > make[6]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote'' > make[5]: *** [subdir-all-ovmf] Error 2 > make[5]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[4]: *** [subdirs-all] Error 2 > make[4]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'' > make: *** [install-tools] Error 2I wish I knew enough about gcc to understand the significance of those two ''unrecognized command line options''. From what Kristian Hagsted Rasmussen said in his post here, "How to set GCC version for ovmf compilation", he seems to think the problem is a gcc version mismatch. Unfortunately for him and myself, no response has been forthcoming on this particular issue. Anyway. if having a UEFI firmware for qemu is no real advantage, I''ll just install the alternate build of Xen I did without OVMF enabled. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
I have only ever used the upstream-qemu to test the performance of generic devices with HVM. I don''t have statistics, but I did see a reduction in boot times and IO performance was better for emulated / layered devices such as Network and Disk Drives. However, the moment I installed PV on HVM drivers, that difference disappeared. I am using IOMMU for passing a wireless NIC to a router, and a graphics card to a multimedia HVM. For that reason I haven''t tried building ovmf or using upstream recently. I think this error is probably the one you should be checking, is there a `--64` flag? gcc: error: unrecognized command line option ‘--64’ To my understanding all these BIOS are emulated, pretty sure the host machines BIOS is unrelated. On Sat, Dec 8, 2012 at 12:33 PM, ShadesOfGrey <shades_of_grey@earthlink.net>wrote:> On 12/07/2012 11:20 PM, Casey DeLorme wrote: > > > Xen 4.2 compiled from source should include both traditional and upstream > qemu. > > Upstream does not have complete passthrough support, if you are doing > anything of that nature best to stick to traditional. > > The Xen Man Pages have the most up to date configuration: > http://wiki.xen.org/wiki/Xen_4.2_Man_Pages > > The flag to set per HVM Configuration is `device_model_version`, its > values are "qemu-xen" and "qemu-xen-traditional", the traditional being the > default. Key benefits are alternative BIOS, though the UEFI BIOS has to be > specified to build when compiling Xen. > > > IIRC, I tried setting the ''device_model_version'' flag to "qemu-dm" and > "qemu-xen". In both cases I got the error message I quoted. If "qemu-dm" > has been deprecated, the error makes sense. If, for some reason, > qemu-upstream didn''t get pulled down, the error would also make sense. I > didn''t try try "qemu-xen-traditional". But that''s only because I''m pretty > sure that, once the other two values failed, I checked the contents of " > /usr/lib/xen-4.2/bin/" and found it had no qemu executables. > > Still, my recollection could be wrong. I thought I had documented most > the non-trivial errors that I encountered. I have a feeling that I lost > some of those I captured after reformatting my Dom0 LV. I was pretty sleep > deprived after two marathon session last week. So, if I forget to backup > my error logs, I could also be misremembering what the results of changing > ''device_model_version'' values were. > > BTW, are there any significant advantages to using the OVMF UEFI > firmware? I thought since my motherboard has an UEFI firmware, having qemu > use an UEFI firmware might somehow be advantageous. However, the last time > I tried compiling Xen with "--enable-ovmf", make bombed out with the > following: > > "/usr/bin/gcc" -c -x assembler -imacros > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG/AutoGen.h > -m64 --64 -melf_x86_64 -o > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/X64 > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include/X64 > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg > -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Include > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.iii > gcc: error: unrecognized command line option ‘--64’ > make[7]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib'' > gcc: error: unrecognized command line option ‘-melf_x86_64’ > make[7]: *** > [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj] > Error 1 > > > build.py... > : error 7000: Failed to execute command > make tbuild > [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib] > > > build.py... > : error F002: Failed to build module > > /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf > [X64, GCC44, DEBUG] > > - Failed - > Build end time: 04:32:20, Dec.08 2012 > Build total time: 00:00:02 > > make[6]: *** [ovmf.bin] Error 1 > make[6]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote'' > make[5]: *** [subdir-all-ovmf] Error 2 > make[5]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[4]: *** [subdirs-all] Error 2 > make[4]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'' > make: *** [install-tools] Error 2 > > I wish I knew enough about gcc to understand the significance of those two > ''unrecognized command line options''. From what Kristian Hagsted Rasmussen > said in his post here, "How to set GCC version for ovmf compilation", he > seems to think the problem is a gcc version mismatch. Unfortunately for > him and myself, no response has been forthcoming on this particular issue. > > Anyway. if having a UEFI firmware for qemu is no real advantage, I''ll just > install the alternate build of Xen I did without OVMF enabled. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 12/08/2012 12:52 PM, Casey DeLorme wrote:> I have only ever used the upstream-qemu to test the performance of > generic devices with HVM. I don''t have statistics, but I did see a > reduction in boot times and IO performance was better for emulated / > layered devices such as Network and Disk Drives. However, the moment > I installed PV on HVM drivers, that difference disappeared. > > I am using IOMMU for passing a wireless NIC to a router, and a > graphics card to a multimedia HVM. For that reason I haven''t tried > building ovmf or using upstream recently. > > I think this error is probably the one you should be checking, is > there a `--64` flag? > > gcc: error: unrecognized command line option ''--64'' > > > To my understanding all these BIOS are emulated, pretty sure the host > machines BIOS is unrelated. >If there is no significant benefit, I''ll use the non-UEFI build for the time being then. I''ll report back on whether I finally succeed or am met, yet again, with failure. As to whether or not there is a "--64" flag, from what I can tell, there isn''t one. Although, I''m not 100% sure what you meant by flag. Did you mean command line option or perhaps an environment variable (e.g. CPPFLAGS)? But it would seem to me, that "--64" is a malformed option. The result of a typo maybe? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users