Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

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.driveA=
libxl: 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.

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Alex Bligh]

--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?

-- 
Alex Bligh

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

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.

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

>
> 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.

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Sander Eikelenboom]

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 ?

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

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'

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Sander Eikelenboom]

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

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

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?


>
> 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

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Sander Eikelenboom]

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

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

>>> 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 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.
>

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Sander Eikelenboom]

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 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.

>>
>>> 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 ?

>>
>>> Thanks for all your help.
>>

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

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.
>
>

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Campbell]

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.

Re: Problem starting HVM guest in Xen 4.3 RC6 when NOT using device_model_version="qemu-xen-traditional"

[Ian Murray]

> 
> 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.