On Wed, 2013-02-13 at 12:56 +0000, Ian Campbell wrote:
I think it should JustWork. I expect they disabled it either because they intended to eventually use /usr/bin/qemu-foo instead or maybe just as an expedient way of getting the 4.2 package together and because it is a non-default option in 4.2 (and something of a "preview" feature at that).
OK... I re-enabled it, I now have a /usr/lib/xen/bin/qemu-system-i386 (not x86_64 but that's fine for now) which *does* appear to have Xen support.
[root@i7 ~]# xl create -c -d seabios.cfg Parsing config from seabios.cfg {"domid":null,"config":{"c_info":{"type":"hvm","hap":"<default>","oos":"<default>","ssidref":0,"name":"seabios","uuid":"849a47f8-1333-45e1-b4a6-cde90429cfd4","xsdata":{},"platformdata":{},"poolid":0,"run_hotplug_scripts":"True"},"b_info":{"max_vcpus":0,"avail_vcpus":[],"cpumap":[],"numa_placement":"<default>","tsc_mode":"default","max_memkb":524288,"target_memkb":524288,"video_memkb":-1,"shadow_memkb":4096,"rtc_timeoffset":0,"localtime":"<default>","disable_migrate":"<default>","cpuid":[],"blkdev_start":null,"device_model_version":"qemu_xen","device_model_stubdomain":"<default>","device_model":null,"device_model_ssidref":0,"extra":[],"extra_pv":[],"extra_hvm":[],"sched_params":{"sched":"unknown","weight":-1,"cap":-1,"period":-1,"slice":-1,"latency":-1,"extratime":-1},"ioports":[],"irqs":[],"u":{"firmware":"/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader","bios":null,"pae":"<default>","apic":"<default>","acpi":"<default>","acpi_s3":"<default>","acpi_s4":"<default>","nx":"<default>","viridian":"<default>","timeoffset":null,"hpet":"<default>","vpt_align":"<default>","timer_mode":null,"nested_hvm":"<default>","nographic":"<default>","vga":{"kind":null},"vnc":{"enable":"<default>","listen":null,"passwd":null,"display":0,"findunused":"<default>"},"keymap":null,"sdl":{"enable":"<default>","opengl":"<default>","display":null,"xauthority":null},"spice":{"enable":"<default>","port":0,"tls_port":0,"host":null,"disable_ticketing":"<default>","passwd":null,"agent_mouse":"<default>"},"gfx_passthru":"<default>","serial":"pty","boot":null,"usb":"<default>","usbdevice":null,"soundhw":null,"xen_platform_pci":"<default>"}},"disks":[],"nics":[],"pcidevs":[],"vfbs":[],"vkbs":[],"on_poweroff":"destroy","on_reboot":"restart","on_watchdog":"destroy","on_crash":"destroy"}} xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->00000000001be3a8 TOTAL: 0000000000000000->000000001f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000000fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 1383 xenconsole: Could not read tty from store: No such file or directory libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 2
At this point, the 'xl create' command is running in the background, appending this to xl-seabios.log every few seconds...
xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->00000000001be3a8 TOTAL: 0000000000000000->000000001f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000000fb 1GB PAGES: 0x0000000000000000 Waiting for domain seabios (domid 253) to die [pid 1384] Domain 253 has shut down, reason code 1 0x1 Action for shutdown reason code 1 is restart Domain 253 needs to be cleaned up: destroying the domain Done. Rebooting now
I can strace it and see that it *is* invoking qemu and then almost immediately sending it a SIGHUP for reasons I don't quite understand.