On Wed, 2013-02-13 at 16:08 +0000, David Woodhouse wrote:
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.
Actually the -i386/x86_64 designator is a bit arbitrary/meaningless since under Xen qemu only implements peripherals and not the actual processor. Even upstream we only ever build one (I forget which) regardless of platform and we use the same one regardless of guest type.
[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...
This usually indicates that either hvmloader or the BIOS is crashing, often with a triple fault. You should see in xl dmesg: "Triple fault on VCPU%d - " "invoking HVM system reset.\n"
Actually, that reminds me, you should add "loglvl=all guest_loglvl=all" to your hypervisor command line.
I think the on_foo = "preserve" stuff I mentioned earlier should stop the annoying constant looping reboots.
Is this is a Seabios you built yourself (modified or un) or the Fedora packaged one?
I've attached an hvmloader which I just built from the 4.2 stable branch and have smoke tested, does it work for you?
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.
The domain died so it is tidying up. Probably qemu barely got the chance to do anything before the guest crashed.
Ian.