Ian Murray
2013-Jun-29 01:33 UTC
Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
Hi, I''ve just tried to start a previously created Windows XP domU only to discover that it won''t start by default under Xen 4.3 RC 5 & RC 6. This started with no problems under 4.2.2 I haven''t been following the changes to the qemu elements of Xen, so I might have missed something or am doing something wrong... but I assumed that a basic HVM guest would start and operate in pretty much the same way as it used to. Anyway, under 4.3 RC 6 when I start it, I get.... root@xen6:/etc/xen# xl create win Parsing config from win xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eac8 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 14 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1075:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1306:libxl__destroy_device_model: Device Model already exited Having had a read, I gather I can re-enable the previous behaviour by adding the line: device_model_version="qemu-xen-traditional". The domain starts as it used to:- root@xen6:/etc/xen# xl create win Parsing config from win xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eac8 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 3712 The only interesting thing that I did that I can recall is that to build it, I used ./configure --prefix=/usr because I was too lazy to track down all the previous installed stuff. The config file is as follows:- #path=''/usr/lib/xen'' #kernel = path+''/boot/hvmloader'' #kernel = ''/usr/lib/xen/boot/hvmloader'' builder=''hvm'' memory = ''2048'' name = ''win'' #device_model_version="qemu-xen-traditional" # boot on floppy (a), hard disk (c) or CD-ROM (d) boot=''c'' disk = [ ''phy:/dev/xen6/win-root,hda,w'' ] vcpus=2 vnc=1 vncviewer=0 vnclisten="0.0.0.0" vncpasswd=''win'' vif=[''mac=00:16:31:01:01:01,bridge=eth0''] on_poweroff = ''destroy'' on_reboot = ''restart'' on_crash = ''restart'' usbdevice=''tablet'' I tried commenting out bits of it (usb,vnc,etc) but that didn''t help. /dev/xen6/win-root is an lvm logical volume. I even tried commenting the disk line out. Below is a verbose version of the failed creation:- root@xen6:/etc/xen# xl -vvvvv create win Parsing config from win libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x22f6690: create: how=(nil) callback=(nil) poller=0x22f66f0 libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch w=0x22ec1d8: deregister unregistered libxl: debug: libxl_numa.c:475:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=2, nr_vcpus=4, free_memkb=15035 libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement candidate with 1 nodes, 2 cpus and 15035 KB free selected xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9eac8 xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19eac8 xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eac8 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x7eff81b8c000 -> 0x7eff81c2194d libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=phy libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22f2858 wpath=/local/domain/0/backend/vbd/16/768/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x22f6690: inprogress: poller=0x22f66f0, flags=i libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22f2858 wpath=/local/domain/0/backend/vbd/16/768/state token=3/0: event epath=/local/domain/0/backend/vbd/16/768/state libxl: debug: libxl_event.c:647:devstate_watch_callback: backend /local/domain/0/backend/vbd/16/768/state wanted state 2 still waiting state 1 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22f2858 wpath=/local/domain/0/backend/vbd/16/768/state token=3/0: event epath=/local/domain/0/backend/vbd/16/768/state libxl: debug: libxl_event.c:643:devstate_watch_callback: backend /local/domain/0/backend/vbd/16/768/state wanted state 2 ok libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x22f2858 wpath=/local/domain/0/backend/vbd/16/768/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch w=0x22f2858: deregister unregistered libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_dm.c:1206:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -xen-domid libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: 16 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -chardev libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-16,server,nowait libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -mon libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -name libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: win libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: 0.0.0.0:0,password,to=99 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -global libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: isa-fdc.driveAlibxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -vga libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: cirrus libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -global libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: vga.vram_size_mb=8 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -boot libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: order=c libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -usb libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -usbdevice libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: tablet libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -smp libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: 2,maxcpus=2 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -device libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: rtl8139,id=nic0,netdev=net0,mac=00:16:31:01:01:01 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -netdev libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: type=tap,id=net0,ifname=vif16.0-emu,script=no,downscript=no libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -M libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: xenfv libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -m libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: 2040 libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: -drive libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: file=/dev/xen6/win-root,if=ide,index=0,media=disk,format=raw,cache=writeback libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22ec410 wpath=/local/domain/0/device-model/16/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22ec410 wpath=/local/domain/0/device-model/16/state token=3/1: event epath=/local/domain/0/device-model/16/state libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x22ec410 wpath=/local/domain/0/device-model/16/state token=3/1: deregister slotnum=3 libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 16 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1075:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1306:libxl__destroy_device_model: Device Model already exited libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x22f5ed8 wpath=/local/domain/0/backend/vbd/16/768/state token=3/2: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x22f5ed8 wpath=/local/domain/0/backend/vbd/16/768/state token=3/2: event epath=/local/domain/0/backend/vbd/16/768/state libxl: debug: libxl_event.c:643:devstate_watch_callback: backend /local/domain/0/backend/vbd/16/768/state wanted state 6 ok libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x22f5ed8 wpath=/local/domain/0/backend/vbd/16/768/state token=3/2: deregister slotnum=3 libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch w=0x22f5ed8: deregister unregistered libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script: /etc/xen/scripts/block remove libxl: debug: libxl_event.c:472:watchfd_callback: watch epath=/local/domain/0/backend/vbd/16/768/state token=3/2: empty slot libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x22f6690: complete, rc=-3 libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x22f6690: destroy xc: debug: hypercall buffer: total allocations:1216 total releases:1216 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:1208 misses:4 toobig:4 Any suggestions would be greatly received. Thanks for reading, Ian.
Alex Bligh
2013-Jun-29 08:35 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
--On 29 June 2013 02:33:06 +0100 Ian Murray <murrayie@yahoo.co.uk> wrote:> libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: > /usr/lib/xen/bin/qemu-system-i386...> libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 16device > model: spawn failed (rc=-3) #define ESRCH 3 /* No such process */ I''m guessing it cqn''t exec /usr/lib/xen/bin/qemu-system-i386 (the new device model). What happens if you just run /usr/lib/xen/bin/qemu-system-i386 from the command line? -- Alex Bligh
Ian Murray
2013-Jun-29 10:49 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
On 29/06/13 09:35, Alex Bligh wrote:> > > --On 29 June 2013 02:33:06 +0100 Ian Murray <murrayie@yahoo.co.uk> wrote: > >> libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: >> /usr/lib/xen/bin/qemu-system-i386 > ... >> libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 16 > device > model: spawn failed (rc=-3) > > #define ESRCH 3 /* No such process */ > > I''m guessing it cqn''t exec /usr/lib/xen/bin/qemu-system-i386 (the new > device model). > > What happens if you just run /usr/lib/xen/bin/qemu-system-i386 from the > command line? >Thanks for your response. I did check the file was there as google suggested I check this. root@xen6:/etc/xen# /usr/lib/xen/bin/qemu-system-i386 VNC server running on `127.0.0.1:5900'' which I then had to interrupt with ctrl-c to get back to a prompt. I have no idea if it is meaningful or not but I strung together the debug output to create a long qemu command and I tried running it.... root@xen6:/etc/xen# /usr/lib/xen/bin/qemu-system-i386 -xen-domid 20 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-20,server,nowait -mon chardev=libxl-cmd,mode=control -name win -vnc 0.0.0.0:0,password,to=99 -global isa-fdc.driveA= -vga cirrus -global vga.vram_size_mb=8 -boot order=c -usb -usbdevice tablet -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:31:01:01:01 -netdev type=tap,id=net0,ifname=vif20.0-emu,script=no,downscript=no -M xenfv -m 2040 -drive file=/dev/xen6/win-root,if=ide,index=0,media=disk,format=raw,cache=writeback qemu: hardware error: map shared IO page returned error 22 handle=0x7f32b3c6e510 Aborted (core dumped) root@xen6:/etc/xen# Also, in ''var/log/xen/qemu-dm-win.log'' it says:- qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' Which might be my overall issue.
Ian Murray
2013-Jun-29 11:33 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
> > Also, in ''var/log/xen/qemu-dm-win.log'' it says:- > > qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' > > Which might be my overall issue. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-develWhen I manually comment out the patch "tools/libxl: Disable useless empty floppy drive with qemu-xen" - http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html ....I get... root@xen6:~/xensource/xen# xl create /etc/xen/win Parsing config from /etc/xen/win xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eac8 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 Daemon running with PID 22958 Starts up fine and is accessible via VNC (albeit with a stupid resolution). I am not sure why this has affected me and not everyone else. I assume "not everyone" for obvious reasons.
Sander Eikelenboom
2013-Jun-29 12:36 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
Saturday, June 29, 2013, 1:33:06 PM, you wrote:>> >> Also, in ''var/log/xen/qemu-dm-win.log'' it says:- >> >> qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' >> >> Which might be my overall issue. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel> When I manually comment out the patch "tools/libxl: Disable useless > empty floppy drive with qemu-xen" - > http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html> ....I get...> root@xen6:~/xensource/xen# xl create /etc/xen/win > Parsing config from /etc/xen/win > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000019eac8 > Modules: 0000000000000000->0000000000000000 > TOTAL: 0000000000000000->000000007f800000 > ENTRY ADDRESS: 0000000000100000 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000003fb > 1GB PAGES: 0x0000000000000000 > Daemon running with PID 22958> Starts up fine and is accessible via VNC (albeit with a stupid > resolution). I am not sure why this has affected me and not everyone > else. I assume "not everyone" for obvious reasons.You are not having any line that mentions "floppy" in your .cfg ?
Ian Murray
2013-Jun-29 12:47 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
On 29/06/13 13:36, Sander Eikelenboom wrote:> Saturday, June 29, 2013, 1:33:06 PM, you wrote: > > >>> Also, in ''var/log/xen/qemu-dm-win.log'' it says:- >>> >>> qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' >>> >>> Which might be my overall issue. >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel > >> When I manually comment out the patch "tools/libxl: Disable useless >> empty floppy drive with qemu-xen" - >> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html >> ....I get... >> root@xen6:~/xensource/xen# xl create /etc/xen/win >> Parsing config from /etc/xen/win >> xc: info: VIRTUAL MEMORY ARRANGEMENT: >> Loader: 0000000000100000->000000000019eac8 >> Modules: 0000000000000000->0000000000000000 >> TOTAL: 0000000000000000->000000007f800000 >> ENTRY ADDRESS: 0000000000100000 >> xc: info: PHYSICAL MEMORY ALLOCATION: >> 4KB PAGES: 0x0000000000000200 >> 2MB PAGES: 0x00000000000003fb >> 1GB PAGES: 0x0000000000000000 >> Daemon running with PID 22958 > >> Starts up fine and is accessible via VNC (albeit with a stupid >> resolution). I am not sure why this has affected me and not everyone >> else. I assume "not everyone" for obvious reasons. > You are not having any line that mentions "floppy" in your .cfg ? > >Only in a comment:- builder=''hvm'' memory = ''2048'' name = ''win'' # boot on floppy (a), hard disk (c) or CD-ROM (d) boot=''c'' disk = [ ''phy:/dev/xen6/win-root,hda,w'' ] vcpus=2 vnc=1 vncviewer=0 vnclisten="0.0.0.0" vncpasswd=''win'' vif=[''mac=00:16:31:01:01:01,bridge=eth0''] on_poweroff = ''destroy'' on_reboot = ''restart'' on_crash = ''restart'' usbdevice=''tablet''
Sander Eikelenboom
2013-Jun-29 13:13 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
Saturday, June 29, 2013, 2:47:40 PM, you wrote:> On 29/06/13 13:36, Sander Eikelenboom wrote: >> Saturday, June 29, 2013, 1:33:06 PM, you wrote: >> >> >>>> Also, in ''var/log/xen/qemu-dm-win.log'' it says:- >>>> >>>> qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' >>>> >>>> Which might be my overall issue. >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >> >>> When I manually comment out the patch "tools/libxl: Disable useless >>> empty floppy drive with qemu-xen" - >>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html >>> ....I get... >>> root@xen6:~/xensource/xen# xl create /etc/xen/win >>> Parsing config from /etc/xen/win >>> xc: info: VIRTUAL MEMORY ARRANGEMENT: >>> Loader: 0000000000100000->000000000019eac8 >>> Modules: 0000000000000000->0000000000000000 >>> TOTAL: 0000000000000000->000000007f800000 >>> ENTRY ADDRESS: 0000000000100000 >>> xc: info: PHYSICAL MEMORY ALLOCATION: >>> 4KB PAGES: 0x0000000000000200 >>> 2MB PAGES: 0x00000000000003fb >>> 1GB PAGES: 0x0000000000000000 >>> Daemon running with PID 22958 >> >>> Starts up fine and is accessible via VNC (albeit with a stupid >>> resolution). I am not sure why this has affected me and not everyone >>> else. I assume "not everyone" for obvious reasons. >> You are not having any line that mentions "floppy" in your .cfg ? >> >>> Only in a comment:-> builder=''hvm'' > memory = ''2048'' > name = ''win'' > # boot on floppy (a), hard disk (c) or CD-ROM (d) > boot=''c'' > disk = [ ''phy:/dev/xen6/win-root,hda,w'' ] > vcpus=2 > vnc=1 > vncviewer=0 > vnclisten="0.0.0.0" > vncpasswd=''win'' > vif=[''mac=00:16:31:01:01:01,bridge=eth0''] > on_poweroff = ''destroy'' > on_reboot = ''restart'' > on_crash = ''restart'' > usbdevice=''tablet''Hmm just checked, xl generates that line for my HVM''s as well, though they do start. And i don''t get that line in my qemu-dm.log Are you sure it runs the qemu that is installed with you last build ? And in fact it is the latest ? Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. Could it be your tools/qemu-xen-dir is also not on the latest commit ? -- Sander
Ian Murray
2013-Jun-29 14:33 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
On 29/06/13 14:13, Sander Eikelenboom wrote:> Saturday, June 29, 2013, 2:47:40 PM, you wrote: > >> On 29/06/13 13:36, Sander Eikelenboom wrote: >>> Saturday, June 29, 2013, 1:33:06 PM, you wrote: >>> >>> >>>>> Also, in ''var/log/xen/qemu-dm-win.log'' it says:- >>>>> >>>>> qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' >>>>> >>>>> Which might be my overall issue. >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xen.org >>>>> http://lists.xen.org/xen-devel >>>> When I manually comment out the patch "tools/libxl: Disable useless >>>> empty floppy drive with qemu-xen" - >>>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html >>>> ....I get... >>>> root@xen6:~/xensource/xen# xl create /etc/xen/win >>>> Parsing config from /etc/xen/win >>>> xc: info: VIRTUAL MEMORY ARRANGEMENT: >>>> Loader: 0000000000100000->000000000019eac8 >>>> Modules: 0000000000000000->0000000000000000 >>>> TOTAL: 0000000000000000->000000007f800000 >>>> ENTRY ADDRESS: 0000000000100000 >>>> xc: info: PHYSICAL MEMORY ALLOCATION: >>>> 4KB PAGES: 0x0000000000000200 >>>> 2MB PAGES: 0x00000000000003fb >>>> 1GB PAGES: 0x0000000000000000 >>>> Daemon running with PID 22958 >>>> Starts up fine and is accessible via VNC (albeit with a stupid >>>> resolution). I am not sure why this has affected me and not everyone >>>> else. I assume "not everyone" for obvious reasons. >>> You are not having any line that mentions "floppy" in your .cfg ? >>> >>> >> Only in a comment:- >> builder=''hvm'' >> memory = ''2048'' >> name = ''win'' >> # boot on floppy (a), hard disk (c) or CD-ROM (d) >> boot=''c'' >> disk = [ ''phy:/dev/xen6/win-root,hda,w'' ] >> vcpus=2 >> vnc=1 >> vncviewer=0 >> vnclisten="0.0.0.0" >> vncpasswd=''win'' >> vif=[''mac=00:16:31:01:01:01,bridge=eth0''] >> on_poweroff = ''destroy'' >> on_reboot = ''restart'' >> on_crash = ''restart'' >> usbdevice=''tablet'' > Hmm just checked, xl generates that line for my HVM''s as well, though they do start. > And i don''t get that line in my qemu-dm.logSorry, which line gets generated?> > Are you sure it runs the qemu that is installed with you last build ?There was a qemu lying around at /usr/local/lib/xen/bin/qemu-system-i386, which I renamed. This made no difference. I renamed /usr/lib/xen/bin/qemu-system-i386 expecting the create to fail badly but is succeeded. It seemed to be falling back to using gemu-dm. So I re-performed make tools-install and the create tried again with qemu-system-i386 but again failed. (slight differences of the error messages, though... but ultimately the same, I think). .... libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: file=/dev/xen6/win-root,if=ide,index=0,media=disk,format=raw,cache=writeback libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x1190380 wpath=/local/domain/0/device-model/30/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x1190380 wpath=/local/domain/0/device-model/30/state token=3/1: event epath=/local/domain/0/device-model/30/state libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x1190380 wpath=/local/domain/0/device-model/30/state token=3/1: deregister slotnum=3 libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 30 device model: spawn failed (rc=-3) ....> And in fact it is the latest ? > > Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk > But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. > > Could it be your tools/qemu-xen-dir is also not on the latest commit ?This is beyond my knowledge, to please persevere with me :) Here are what I think are the relevant bits of my Config.mk. That qemu commit ID seems to match the change in the last commit before RC6, according to gitweb. How can I tell if tools/qemu-xen-dir matches this? I think I will make a new clone of Xen. Thanks for all your help. ifeq ($(GIT_HTTP),y) OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git else OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git endif OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c SEABIOS_UPSTREAM_TAG ?= 3a28511b46f0c2af5fae1b6ed2b0c19d7913cee3 # Wed Jun 26 16:30:45 2013 +0100 # xen: Don''t perform SMP setup. ETHERBOOT_NICS ?= rtl8139 8086100e # Specify which qemu-dm to use. This may be `ioemu'' to use the old # Mercurial in-tree version, or a local directory, or a git URL. # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git CONFIG_QEMU ?= $(QEMU_REMOTE) QEMU_TAG ?= 13c144d96e825f145e5b37f97e5f6210c2c645e9> > > -- > Sander > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Sander Eikelenboom
2013-Jun-29 14:40 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
Saturday, June 29, 2013, 4:33:49 PM, you wrote:> On 29/06/13 14:13, Sander Eikelenboom wrote: >> Saturday, June 29, 2013, 2:47:40 PM, you wrote: >> >>> On 29/06/13 13:36, Sander Eikelenboom wrote: >>>> Saturday, June 29, 2013, 1:33:06 PM, you wrote: >>>> >>>> >>>>>> Also, in ''var/log/xen/qemu-dm-win.log'' it says:- >>>>>> >>>>>> qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value '''' >>>>>> >>>>>> Which might be my overall issue. >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-devel mailing list >>>>>> Xen-devel@lists.xen.org >>>>>> http://lists.xen.org/xen-devel >>>>> When I manually comment out the patch "tools/libxl: Disable useless >>>>> empty floppy drive with qemu-xen" - >>>>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html >>>>> ....I get... >>>>> root@xen6:~/xensource/xen# xl create /etc/xen/win >>>>> Parsing config from /etc/xen/win >>>>> xc: info: VIRTUAL MEMORY ARRANGEMENT: >>>>> Loader: 0000000000100000->000000000019eac8 >>>>> Modules: 0000000000000000->0000000000000000 >>>>> TOTAL: 0000000000000000->000000007f800000 >>>>> ENTRY ADDRESS: 0000000000100000 >>>>> xc: info: PHYSICAL MEMORY ALLOCATION: >>>>> 4KB PAGES: 0x0000000000000200 >>>>> 2MB PAGES: 0x00000000000003fb >>>>> 1GB PAGES: 0x0000000000000000 >>>>> Daemon running with PID 22958 >>>>> Starts up fine and is accessible via VNC (albeit with a stupid >>>>> resolution). I am not sure why this has affected me and not everyone >>>>> else. I assume "not everyone" for obvious reasons. >>>> You are not having any line that mentions "floppy" in your .cfg ? >>>> >>>> >>> Only in a comment:- >>> builder=''hvm'' >>> memory = ''2048'' >>> name = ''win'' >>> # boot on floppy (a), hard disk (c) or CD-ROM (d) >>> boot=''c'' >>> disk = [ ''phy:/dev/xen6/win-root,hda,w'' ] >>> vcpus=2 >>> vnc=1 >>> vncviewer=0 >>> vnclisten="0.0.0.0" >>> vncpasswd=''win'' >>> vif=[''mac=00:16:31:01:01:01,bridge=eth0''] >>> on_poweroff = ''destroy'' >>> on_reboot = ''restart'' >>> on_crash = ''restart'' >>> usbdevice=''tablet'' >> Hmm just checked, xl generates that line for my HVM''s as well, though they do start. >> And i don''t get that line in my qemu-dm.log > Sorry, which line gets generated?I don''t have the error "qemu-system-i386: Property ''isa-fdc.driveA'' can''t find value ''''", although my hvm''s qemu also gets the "-global isa-fdc.driveA=" passed to it>> >> Are you sure it runs the qemu that is installed with you last build ? > There was a qemu lying around at > /usr/local/lib/xen/bin/qemu-system-i386, which I renamed. This made no > difference. I renamed /usr/lib/xen/bin/qemu-system-i386 expecting the > create to fail badly but is succeeded. It seemed to be falling back to > using gemu-dm.> So I re-performed make tools-install and the create tried again with > qemu-system-i386 but again failed. (slight differences of the error > messages, though... but ultimately the same, I think).> .... > libxl: debug: libxl_dm.c:1208:libxl__spawn_local_dm: > file=/dev/xen6/win-root,if=ide,index=0,media=disk,format=raw,cache=writeback > libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch > w=0x1190380 wpath=/local/domain/0/device-model/30/state token=3/1: > register slotnum=3 > libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x1190380 > wpath=/local/domain/0/device-model/30/state token=3/1: event > epath=/local/domain/0/device-model/30/state > libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch > w=0x1190380 wpath=/local/domain/0/device-model/30/state token=3/1: > deregister slotnum=3 > libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 30 > device model: spawn failed (rc=-3)> ....>> And in fact it is the latest ? >> >> Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk >> But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. >> >> Could it be your tools/qemu-xen-dir is also not on the latest commit ?> This is beyond my knowledge, to please persevere with me :)> Here are what I think are the relevant bits of my Config.mk. That qemu > commit ID seems to match the change in the last commit before RC6, > according to gitweb.> How can I tell if tools/qemu-xen-dir matches this?Just do a git log in the tools/qemu-xen-dir and seem what the latest commit is (and compare to what it should be according to the Config.mk). When you are working with an old xen clone it seems you also have the change running an old(er) qemu since it doesn''t seem to be auto updated to the commit id from the Config.mk> I think I will make a new clone of Xen.A fresh clone should fix that up since that also pulls a fresh qemu tree in.> Thanks for all your help.> ifeq ($(GIT_HTTP),y) > OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git > QEMU_UPSTREAM_URL ?= > http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git > else > OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git > QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git > SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > endif > OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871 > QEMU_UPSTREAM_REVISION ?= 1c514a7734b7f98625a0d18d5e8ee7581f26e50c > SEABIOS_UPSTREAM_TAG ?= 3a28511b46f0c2af5fae1b6ed2b0c19d7913cee3 > # Wed Jun 26 16:30:45 2013 +0100 > # xen: Don''t perform SMP setup.> ETHERBOOT_NICS ?= rtl8139 8086100e> # Specify which qemu-dm to use. This may be `ioemu'' to use the old > # Mercurial in-tree version, or a local directory, or a git URL. > # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git > CONFIG_QEMU ?= $(QEMU_REMOTE)> QEMU_TAG ?= 13c144d96e825f145e5b37f97e5f6210c2c645e9>> >> >> -- >> Sander >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
Ian Murray
2013-Jun-29 16:45 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
>>> And in fact it is the latest ? >>> >>> Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk >>> But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. >>> >>> Could it be your tools/qemu-xen-dir is also not on the latest commit ?Yes, you were correct. Well done and thank-you.>> This is beyond my knowledge, to please persevere with me :) >> Here are what I think are the relevant bits of my Config.mk. That qemu >> commit ID seems to match the change in the last commit before RC6, >> according to gitweb. >> How can I tell if tools/qemu-xen-dir matches this? > Just do a git log in the tools/qemu-xen-dir and seem what the latest commit is (and compare to what it should be according to the Config.mk).I did try this but I wasn''t convinced I understood what I was looking at. Here is the top few lines... commit 59e2fb7252dbdc008a63d144b19be0cd8d873128 Author: Felipe Franciosi <felipe.franciosi@xxxxxx.com> Date: Fri Apr 5 15:47:59 2013 +0000> When you are working with an old xen clone it seems you also have the change running an old(er) qemu since it doesn''t seem to be auto updated to the commit id from the Config.mkI am not quite following your logic here. Without understanding how it actually does it, I would presume the logical thing to do is to bring the repository up to date then checkout the specified commit. This wouldn''t necessarily be the latest commit as you may wish to go back in time. OTH if it can''t checkout the required commit IMHO it should be a fatal situation because you can end-up in an unknown state (like I did). Maybe I am misunderstanding what is at work here> >> I think I will make a new clone of Xen. > A fresh clone should fix that up since that also pulls a fresh qemu tree in.Which it did. Thanks again> >> Thanks for all your help. >
Sander Eikelenboom
2013-Jun-29 20:34 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
Saturday, June 29, 2013, 6:45:21 PM, you wrote:>>>> And in fact it is the latest ? >>>> >>>> Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk >>>> But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. >>>> >>>> Could it be your tools/qemu-xen-dir is also not on the latest commit ? > Yes, you were correct. Well done and thank-you.>>> This is beyond my knowledge, to please persevere with me :) >>> Here are what I think are the relevant bits of my Config.mk. That qemu >>> commit ID seems to match the change in the last commit before RC6, >>> according to gitweb. >>> How can I tell if tools/qemu-xen-dir matches this? >> Just do a git log in the tools/qemu-xen-dir and seem what the latest commit is (and compare to what it should be according to the Config.mk). > I did try this but I wasn''t convinced I understood what I was looking > at. Here is the top few lines...> commit 59e2fb7252dbdc008a63d144b19be0cd8d873128 > Author: Felipe Franciosi <felipe.franciosi@xxxxxx.com> > Date: Fri Apr 5 15:47:59 2013 +0000>> When you are working with an old xen clone it seems you also have the change running an old(er) qemu since it doesn''t seem to be auto updated to the commit id from the Config.mk > I am not quite following your logic here. Without understanding how it > actually does it, I would presume the logical thing to do is to bring > the repository up to date then checkout the specified commit. This > wouldn''t necessarily be the latest commit as you may wish to go back in > time. OTH if it can''t checkout the required commit IMHO it should be a > fatal situation because you can end-up in an unknown state (like I did).> Maybe I am misunderstanding what is at work hereYes it''s not very ideal. Since the xen build depends on other git trees (seabios, qemu) and these are pulled automatically on the first build after a clone. It''s not strange to assume that these trees also get updates automatically when you update you local xen tree. But it seems to be not a valid assumption :-) Don''t know if it is easy to fix, because it could interfere with the workflow of active developers/maintainers i guess.>> >>> I think I will make a new clone of Xen. >> A fresh clone should fix that up since that also pulls a fresh qemu tree in.> Which it did. Thanks againSo after a fresh clone and build of the xen tree your hvm guests now boots without problem ?>> >>> Thanks for all your help. >>
Ian Murray
2013-Jun-29 21:07 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
When you are working with an old xen clone it seems you also have the change running an old(er) qemu since it doesn''t seem to be auto updated to the commit id from the Config.mk>> I am not quite following your logic here. Without understanding how it >> actually does it, I would presume the logical thing to do is to bring >> the repository up to date then checkout the specified commit. This >> wouldn''t necessarily be the latest commit as you may wish to go back in >> time. OTH if it can''t checkout the required commit IMHO it should be a >> fatal situation because you can end-up in an unknown state (like I did). >> Maybe I am misunderstanding what is at work here > Yes it''s not very ideal. Since the xen build depends on other git trees (seabios, qemu) and these are pulled automatically on the first build after a clone. > It''s not strange to assume that these trees also get updates automatically when you update you local xen tree. But it seems to be not a valid assumption :-) > > Don''t know if it is easy to fix, because it could interfere with the workflow of active developers/maintainers i guess.It seems as if a ''make distclean'' removes these repositories whereas make clean doesn''t. I think you alluded to this earlier, but I didn''t pick up on at the time. Once I did a ''make distclean'', my original repository re-cloned what it needed and all was good. I had been using ''make clean''. The cloning code is in a script:- #!/bin/sh if test $# -lt 3; then echo "Usage: $0 <tree> <tag> <dir>" exit 1 fi TREE=$1 TAG=$2 DIR=$3 set -e if test \! -d $DIR-remote; then rm -rf $DIR-remote $DIR-remote.tmp mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp $GIT clone $TREE $DIR-remote.tmp if test "$TAG" ; then cd $DIR-remote.tmp $GIT branch -D dummy >/dev/null 2>&1 ||: $GIT checkout -b dummy $TAG cd .. fi mv $DIR-remote.tmp $DIR-remote fi rm -f $DIR ln -sf $DIR-remote $DIR As far as I can tell does not much if the folder is already there :(> >>>> I think I will make a new clone of Xen. >>> A fresh clone should fix that up since that also pulls a fresh qemu tree in. >> Which it did. Thanks again > So after a fresh clone and build of the xen tree your hvm guests now boots without problem ?Yes, that is exactly it. A "make distclean" on my old one also yielded success. Thanks again for your assistance. A credit to community. :)> >>>> Thanks for all your help. > >
Ian Campbell
2013-Jul-01 08:35 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
On Sat, 2013-06-29 at 16:40 +0200, Sander Eikelenboom wrote:> >> And in fact it is the latest ? > >> > >> Hrmmm it seems a make clean && git pull && make in the xen dir, does update the commit id for the qemu tree in Config.mk > >> But the tree it self in /tools/qemu-xen-dir doesn''t seem to be updated accordingly .. > >> > >> Could it be your tools/qemu-xen-dir is also not on the latest commit ? > > > This is beyond my knowledge, to please persevere with me :) > > > Here are what I think are the relevant bits of my Config.mk. That qemu > > commit ID seems to match the change in the last commit before RC6, > > according to gitweb. > > > How can I tell if tools/qemu-xen-dir matches this? > > Just do a git log in the tools/qemu-xen-dir and seem what the latest commit is (and compare to what it should be according to the Config.mk). > When you are working with an old xen clone it seems you also have the change running an old(er) qemu since it doesn''t seem to be auto updated to the commit id from the Config.mk > > > I think I will make a new clone of Xen. > > A fresh clone should fix that up since that also pulls a fresh qemu tree in.You can also run "make tools/qemu-xen-dir-force-update" (simlarly for tools/qemu-xen-traditional-dir-force-update and tools/firmware/seabios-dir-force-update). We could really do with a rule which depends on all of those to force everything to be updated. The reason we don''t do this automatically is we are wary of destroying people''s local changes/work. A local commit is one thing (you can get it back from the reflog) but we were more concerned about dirty trees i.e. losing work which hasn''t been committed. It''s certainly likely that the git cloning runes here could be made smarter. One approach might be to stash the git tag which the build system checked out in a hidden file (tools/.qemu-xen-dir.sha1?) and only force the update if it is the same as the current head, different to the desired head and the tree is not dirty. It could also print bigger warning messages when one or more of these isn''t the case. scripts/git-checkout.sh is the place for anyone wanting to improve the situation here to look. Ian.
Ian Murray
2013-Jul-01 12:26 UTC
Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"
> > You can also run "make tools/qemu-xen-dir-force-update" (simlarly for > tools/qemu-xen-traditional-dir-force-update and > tools/firmware/seabios-dir-force-update). We could really do with a rule > which depends on all of those to force everything to be updated. > > The reason we don''t do this automatically is we are wary of destroying > people''s local changes/work. A local commit is one thing (you can get it > back from the reflog) but we were more concerned about dirty trees i.e. > losing work which hasn''t been committed. > > It''s certainly likely that the git cloning runes here could be made > smarter. One approach might be to stash the git tag which the build > system checked out in a hidden file (tools/.qemu-xen-dir.sha1?) and only > force the update if it is the same as the current head, different to the > desired head and the tree is not dirty. It could also print bigger > warning messages when one or more of these isn''t the case. > > scripts/git-checkout.sh is the place for anyone wanting to improve the > situation here to look.It''s not a mistake I am likely to make again, but I am sure I will not be the last. Even a warning message that the qemus and seabios will not be brought up-to-date, when performing a ''make clean'' might be enough IMHO.