WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Unable to run windows HVM guests with xen 3.1.1

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Unable to run windows HVM guests with xen 3.1.1
From: Guillaume Rousse <Guillaume.Rousse@xxxxxxxx>
Date: Mon, 03 Dec 2007 15:14:00 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 03 Dec 2007 06:14:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200712030300.09944.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <473A1B82.4070001@xxxxxxxx> <200712030300.09944.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071128)
Mark Williamson wrote:
I found another issue with the mandriva xen package: I'm unable anymore
to run windows HVM guests that worked perfectly before. Neither the
existing image, nor installing from the ISO works. In both case, the
domU domain is created, then hangs in early boot phase.

Weird; what version of Xen *was* this working under? Are you using 32-bit or 64-bit guests?
It was working with xen 3.1 on mandriva 2007.0 (prior to update), and failed with xen 3.1 on mandriva 2008.0 (after update). And the guest was
Windows XP, 32 bits.

stracing the qemu-dm process show it looping around the following
syscalls: http://www.pastebin.ca/772441

I can't connect to that host; could you paste some of the output into the e-mail. This'll also help document what happened in the archives.
[pid 7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674333878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674477878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674583878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674629878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679323878}) = 0
[pid 7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679813878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679968878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680026878}) = 0
[pid 7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 2 (in [13 16], left {0, 10000}) [pid 7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680256878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680470878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680601878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680672878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685065878}) = 0
[pid 7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685553878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685679878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685789878}) = 0
[pid 7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 2 (in [13 16], left {0, 10000}) [pid 7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686011878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686224878}) = 0
[pid  7579] mlock(0x7fffff119dd0, 4)    = 0
[pid  7579] ioctl(7, SNDCTL_DSP_RESET, 0x7fffff119de0) = 0
[pid  7579] munlock(0x7fffff119dd0, 4)  = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686530878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686617878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 691162878}) = 0
[pid 7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 691641878}) = 0
[pid  7579] lseek(6, 65536, SEEK_SET)   = 65536
[pid 7579] read(6, ",\0002`\0\0\0\0`2\220\22\0\0\0\0\22\220h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0415.DL_,\0005`\0\0\0\0`5d\n\0\0\0\0\ndh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0415.HL_,\0007`\0\0\0\0`7\266\21\0\0\0\0\21\266h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0416.DL_,\0:`\0\0\0\0`:\0\n\0\0\0\0\n\0h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0416.HL_,\0<`\0\0\0\0`<\200\22\0\0\0\0\22\200h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0419.DL_,\0?`\0\0\0\0`?\16\n\0\0\0\0\n\16h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0419.HL_,\0A`\0\0\0\0`A\250\21\0\0\0\0\21\250h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041D.DL_,\0D`\0\0\0\0`DT\v\0\0\0\0\vTh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041D.HL_,\0F`\0\0\0\0`F\242\21\0\0\0\0\21\242h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041F.DL_,\0I`\0\0\0\0`I\254\n\0\0\0\0\n\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041F.HL_,\0K`\0\0\0\0`K\272\17\0\0\0\0\17\272h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0804.DL_,\0M`\0\0\0\0`M\22\10\0\0\0\0\10\22h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0804.HL_,\0O`\0\0\0\0`O\322\21\0\0\0\0\21\322h\10\5\5\0\0\354
\0\0\0\1\0\0\1\vAGT0816.DL_,\0R`\0\0\0\0`R\34\n\0\0\0\0\n\34h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0816.HL_,\0T`\0\0\0\0`T\254\21\0\0\0\0\21\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0C0A.DL_,\0W`\0\0\0\0`W\32\n\0\0\0\0\n\32h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0C0A.HL_,\0Y`\0\0\0\0`Y}\26\0\0\0\0\26}h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTCORE.JS_.\0\\`\0\0\0\0`\\{\25\0\0\0\0\25{h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTCTL15.TL_\0,\0_`\0\0\0\0`_(\v\0\0\0\0\v(h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTINST.IN_,\0a`\0\0\0\0`aX.\0\0\0\0.Xh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTINTL.DL_.\0g`\0\0\0\0`g\16\4\0\0\0\0\4\16h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTSCRP2.JS_\0.\0h`\0\0\0\0`h\254\200\0\0\0\0\200\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTSCRPT.JS_\0,\0y`\0\0\0\0`yf\37\0\0\0\0\37fh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAHA154X.SY_,\0}`\0\0\0\0`}\4\\\0\0\0\0\\\4h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAHRONBD.TT_*\0\211`\0\0\0\0`\211\243\276\0\0\0\0\276\243h\10\5\5\0\0\354\0\0\0\1\0\0\1\10AHUI.EX_\0,\0\241`\0\0\0\0`\241\330t\0\0\0\0t\
330h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAIC78U2.SY_,\0\260`\0\0\0\0`\260\30w\0\0\0\0w\30h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAIC78XX.SY_,\0\277`\0\0\0\0`\277\317\35\0\0\0\0\35\317h\7\34\f48\354\0\0\0\1\0\0\1\vAICHMGT.CAT,\0\303`\0\0\0\0`\303\371\5\0\0\0\0\5\371h\3\3\26\2\30\354\0\0\0\1\0\0\1\vAICHMGT.INF.\0\304`\0\0\0\0`\304\257\17\0\0\0\0\17\257h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAIRPLANE.BM_\0.\0\306`\0\0\0\0`\306\373\36\0\0\0\0\36\373h\10\5\5\0\0\354\0\0\0\1\0\0\1\fALEABANR.GI_\0(\0\312`\0\0\0\0`\312,E\0\0\0\0E,h\10\5\5\0\0\354\0\0\0\1\0\0\1\7ALG.EX_,\0\323`\0\0\0\0`\323\27\v\0\0\0\0\v\27h\10\5\5\0\0\354\0\0\0\1\0\0\1\nALIIDE.SY_\0,\0\325`\0\0\0\0`\325;$\0\0\0\0$;h\10\5\5\0\0\354\0\0\0\1\0\0\1\nALRSVC.DL_\0.\0\332`\0\0\0\0`\332\275\10\0\0\0\0\10\275h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAMAIZRUL.GI_\0,\0\334`\0\0\0\0`\334\263\3\0\0\0\0\3\263h\10\5\5\0\0\354\0\0\0\1\0\0\1\nAMIPRO.SA_\0,\0\335`\0\0\0\0`\335m\34\0\0\0\0\34mh\10\5\5\0\0\354\0\0\0\1\0\0\1\nAMSINT.SY_\0.\0\341`\0\0\0\0`\341\235y\0\0
\0\0y\235h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAMSTREAM.DL_\0,\0\361`\0\0\0\0`\361\272<\0\0\0\0<\272h\10\5\5\0\0\354\0\0\0\1\0\0\1\vANABNR2.GI_,\0\371`\0\0\0\0`\371\3\273\0\0\0\0\273\3h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANDLSO.TT_\0*\0\21a\0\0\0\0a\21\362\370\0\0\0\0\370\362h\10\5\5\0\0\354\0\0\0\1\0\0\1\tANGSA.TT_,\0001a\0\0\0\0a1\207\356\0\0\0\0\356\207h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAB.TT_\0,\0Oa\0\0\0\0aO\355\270\0\0\0\0\270\355h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAI.TT_\0,\0ga\0\0\0\0ag\315\370\0\0\0\0\370\315h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAU.TT_\0,\0\207a\0\0\0\0a\207\214\356\0\0\0\0\356\214h\10\5\5\0\0\354\0\0\0\1\0\0\1\vANGSAUB.TT_,\0\245a\0\0\0\0a\245\10\271\0\0"..., 2048) = 2048
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709208878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709290878}) = 0
[pid 7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 1 (in [16], left {0, 10000}) [pid 7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709519878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709586878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709652878}) = 0

I couldn't attach strace early enough to catch what is fd 17 exactly,
tough.

Running Linux HVM guests works OK, tough. I only tested this in cooker
(mandriva devel version) on x86_64 host, with xen 3.1.1 (my attempt to
test 3.1 on stable release failed because of the other xend crash issue).

32-bit or 64-bit Linux?
This happened on 64 bit linux.

Strangely, everything works OK now after a reboot, a minor update of xen package (just adding squashfs support), and a different ordering of network configuration at startup (no more explicit bridge setup before launching xend). My assumption is that xen is over-sensible to current network configuration: if you ever have a misconfigured interface or bridge, strange things may happen, such as already reported at:
http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00128.html
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>