Re: [Qemu-devel] [Bug 1034423] Re: Guests running OpenIndiana (and relatives) fail to boot on AMD hardware

[Owen Tuz]

This is an old ticket! I had completely forgotten about it, but will test
when I get a chance and let you know.

Cheers,

Owen

On Fri, May 19, 2017 at 11:25 AM, Thomas Huth <1034...@bugs.launchpad.net>
wrote:

> Triaging old bug tickets ... can you still reproduce this issue with the
> latest version of QEMU (currently v2.9)?
>
> ** Changed in: qemu
>Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1034423
>
> Title:
>   Guests running OpenIndiana (and relatives) fail to boot on AMD
>   hardware
>
> Status in QEMU:
>   Incomplete
>
> Bug description:
>   First observed with OpenSolaris 2009.06, and also applies to the
>   latest OpenIndiana release.
>
>   Version: qemu-kvm 1.1.1
>
>   Hardware:
>
>   2 x AMD Opteron 6128 8-core processors, 64GB RAM.
>
>   These guests boot on equivalent Intel hardware.
>
>   To reproduce:
>
>   qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
>   -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
>   151a5-live-x86.iso -boot order=dc
>
>   I've tested with "-vga std" and various different emulated CPU types,
>   to no effect.
>
>   What happens:
>
>   GRUB loads, and offers multiple boot options, but none work. Some kind
>   of kernel panic flies by very fast before restarting the VM, and
>   careful use of the screenshot button reveals that it reads as follows:
>
>   panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
>   rp=fec2b48c add r=0
>
>   #df Double fault
>   pid=0, pc=0xault
>   pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
>   cr0: 80050011 cr4:b8
>   cr2: 0cr3: ae2f000
> gs:1b0fs:  0   es:
>  160   ds:  160
>edi:0  esi:  0 ebp:
>  0 esp: fec2b4c4
>ebx: c0010015 edx:  0 ecx: 0 eax:
> fec40400
>trp: 8  err:  0 eip: fe800377
> cs:   158
>efl: 202 usp: fec40090  ss:   160
>   tss.tss_link: 0x0
>   tss.tss_esp0:   0x0
>   tss.tss_ss0: 0x160
>   tss.tss_esp1:   0x0
>   tss.tss_ss1:  0x0
>   tss.tss esp2: 0x0
>   tss.tss_ss2:  0x0
>   tss.tss_cr3:   0xae2f000
>   tss.tss_eip:   0xfec40400
>   tss.tss_eflags:  0x202
>   tss.tss_eax:  0xfec40400
>   tss.tss_ebx:  0xc0010015
>   tss.tss_ecx:  0xc001
>   tss.tss_edx:  0x0
>   tss.tss_esp:  0xfec40090
>
>   Warning - stack not written to the dumpbuf
>   fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
>   fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
>   fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)
>
>   If there's any more, I haven't managed to catch it.
>
>   Solaris 11 does not seem to suffer from the same issue, although the
>   first message that appears at boot (after the version info) is "trap:
>   Unkown trap type 8 in user mode". Could be related?
>
>   As always, thanks in advance and please let me know if I can help to
>   test, or provide any more information.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1034423/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1034423

Title:
  Guests running OpenIndiana (and relatives) fail to boot on AMD
  hardware

Status in QEMU:
  Incomplete

Bug description:
  First observed with OpenSolaris 2009.06, and also applies to the
  latest OpenIndiana release.

  Version: qemu-kvm 1.1.1

  Hardware:

  2 x AMD Opteron 6128 8-core processors, 64GB RAM.

  These guests boot on equivalent Intel hardware.

  To reproduce:

  qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
  -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
  151a5-live-x86.iso -boot order=dc

  I've tested with "-vga std" and various different emulated CPU types,
  to no effect.

  What happens:

  GRUB loads, and offers multiple boot options, but none work. Some kind
  of kernel panic flies by very fast before restarting the VM, and
  careful use of the screenshot button reveals that it reads as follows:

  panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
  rp=fec2b48c add r=0

  #df Double fault
  pid=0, pc=0xault
  pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
  cr0: 80050011 cr4:b8
  cr2: 0cr3: ae2f000
gs:1b0fs:  0   es: 160   
ds:  160
   edi:0  esi:  0 ebp: 0 
esp: fec2b4c4
   ebx: c0010015 edx:  0 ecx: 0 eax: 
fec40400
   trp: 8  err:  0 eip: fe800377  cs:   
158
   efl: 202 usp: fec40090  ss:   160
  tss.tss_link: 

Re: [Qemu-devel] xsave instruction not passed through correctly on AMD hardware

[Owen Tuz]

Great, thanks for the clarification. Testing with kvm-next shows that this
is still true in the latest build.

Best regards,

Owen


On Mon, Nov 11, 2013 at 4:56 PM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 11/11/2013 16:43, Owen Tuz ha scritto:
  Thanks, Paolo. We will test and let you know.
  I'm not familiar with LWP (some reading to do there) - are there any
  plans to support this in future, or is this just something that we're
  not interested in emulating?

 Given Linux does not support LWP, and AMD is not really trying to
 compete with Intel anymore, it is quite unlikely that KVM will support
 LWP in the future.

 Paolo

[Qemu-devel] xsave instruction not passed through correctly on AMD hardware

[Owen Tuz]

Hi all,

We've been seeing a problem lately running FreeBSD 9.1 and 9.2 (latest
stable) which causes the guest to crash during boot when QEMU is run on an
AMD processor with the 'xsave' flag set.

To reproduce this behaviour:

- Boot a FreeBSD 9.1 or 9.2 guest or even installation CD on an AMD
processor with xsave enabled. Use '-cpu host'.

- After the bootloader, the guest will crash almost immediately with the
message 'kernel trap 12 with interrupts disabled'. This occurs before any
disks are loaded, so it's not possible to get a memory dump from the guest
OS for backtrace.

- Boot again with '-cpu host,-xsave'. The guest should boot successfully.

This was seen on AMD Opteron 6238 processor family, and does not affect our
Opteron 6128s (due to lack of the xsave flag).

We've also tested on an Intel Xeon E5-2640 processor which has the xsave
flag set and verified that we do not see this behaviour.

Based on this, I believe that the xsave instruction is not being correctly
emulated on some hardware. Is this a known issue?

Thanks in advance for looking, and please let me know if we can provide any
more useful information to help diagnose/fix this.

Best regards,

Owen Tuz

Re: [Qemu-devel] xsave instruction not passed through correctly on AMD hardware

[Owen Tuz]

Thanks, Paolo. We will test and let you know.
I'm not familiar with LWP (some reading to do there) - are there any plans
to support this in future, or is this just something that we're not
interested in emulating?

Best regards,

Owen


On Mon, Nov 11, 2013 at 3:25 PM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 11/11/2013 15:30, Owen Tuz ha scritto:
  Hi all,
 
  We've been seeing a problem lately running FreeBSD 9.1 and 9.2 (latest
  stable) which causes the guest to crash during boot when QEMU is run on
  an AMD processor with the 'xsave' flag set.
 
  To reproduce this behaviour:
 
  - Boot a FreeBSD 9.1 or 9.2 guest or even installation CD on an AMD
  processor with xsave enabled. Use '-cpu host'.
 
  - After the bootloader, the guest will crash almost immediately with the
  message 'kernel trap 12 with interrupts disabled'. This occurs before
  any disks are loaded, so it's not possible to get a memory dump from the
  guest OS for backtrace.
 
  - Boot again with '-cpu host,-xsave'. The guest should boot successfully.

 This is probably cause by the lightweight profiling XSAVE extension.
 KVM does not support it.  Using -cpu host may show problems when the
 CPU has features that are not supported by KVM.

 It's possible though that this has been recently fixed.  Please try
 branch next of git://git.kernel.org/pub/scm/virt/kvm/kvm.git and
 report back.

 Paolo

[Qemu-devel] Bug: E1000 kernel panic when transferring files over private network

[Owen Tuz]

We are seeing a reliably reproducible panic when using the E1000 card over
a private network. This crash occurs inside the guest kernel of a VM with
some (we believe) unrelated network connectivity issues, running on
qemu-kvm 1.1.1.

We have seen this on all kernel versions we tested, the earliest version
being 2.6.32-5 on a Debian test VM. I can provide error messages from other
kernel versions or distributions for comparison if it would be useful.

To reproduce:

Add two machines to a VLAN where 192.168.0.1 is serving some file
('test.bin'), and 192.168.0.2 is using the Intel E1000 card.

From 192.168.0.2:

wget -O /dev/null http://192.168.0.1/test.bin

On Arch Linux running 3.5.1-1 this produces a kernel panic as follows,
within a few seconds:

[ 151.310977] BUG: unable to handle kernel paging request at 51c39a07
[ 151.314106] IP: [c01f35a8] put_page+0x8/0x40
[ 151.314106] *pde = 
[ 151.314106] Oops:  [#1] PREEMPT SMP
[ 151.314106] Modules linked in: cirrus syscopyarea sysfillrect sysimgblt
drm_kms_helper ttm i2c_piix4 drm
serio_raw intel_agp microcode intel_gtt agpgart kvm_amd e1000 pcspkr
i2c_core_processor joydev button psmouse evdev
kvm ext4 crc16 jbd2 mbcache hid_generic usbhid sd_mod pata_acpi ata_generic
ata_piix uhci_hcd usbcore usb_common
libata scsi_mod floppy
[ 151.314106]
[ 151.314106] Pid: 387, comm: wget Not tainted 3.5.1-1-ARCH #1 Bochs Bochs
[ 151.314106] EIP: 0060:[c01f35a8] EFLAGS: 00210202 CPU: 0
[ 151.314106] EIP is at put_page+0x8/0x40
[ 151.314106] EAX: 51c39a07 EBX: 0001 ECX: c07acdb8 EDX: ce350d40
[ 151.314106] ESI: cea51480 EDI: 05a8 EBP: ce133da4 ESP: ce133da4
[ 151.314106]  DS: 007b ES: 007b FS:00d8 GS: 00e0 SS: 0068
[ 151.314106] CR0: 80050033 CR2: 51c39a07 CR3: 0ec54000 CR4: 06d0
[ 151.314106] DR0:  DR1:  DR2:  DR3: 
[ 151.314106] DR6: 0ff0 DR7: 0400
[ 151.314106] Process wget (pid: 387, ti=ce132000 task=cea92a80
task.ti=ce132000)
[ 151.314106] Stack:
[ 151.314106]  ce133db4 c03deb8c cea51480 ce03c000 ce133dc0 c03debe7
cea51480 ce133e28
[ 151.314106]  c0424bbc  ce1b5d20 ce133e38 ce133e08 c0334661
0001 0010
[ 151.314106]  6b5f2c4b cea92a80  0001 ce133e9c 
0001 05a8
[ 151.314106] Call Trace:
[ 151.314106]  [c03deb8c] skb_release_data+0x6c/0xb0
[ 151.314106]  [c03debe7] __kfree_skb+0x17/0x90
[ 151.314106]  [c0424bbc] tcp_recvmsg+0x92c/0xb40
[ 151.314106]  [c0334661] ? soft_cursor+0x191/0x200
[ 151.314106]  [c0442eab] inet+recvmsg+0x6b/0xb0
[ 151.314106]  [c03d6584] sock_aio_read+0x114/0x150
[ 151.314106]  [c0234237] do_sync_read+0xb7/0xf0
[ 151.314106]  [c012a5dc] ? pvclock_clocksource_read+0xec/0x150
[ 151.314106]  [c02a7ce4] ? security_file_permission+0x94/0xb0
[ 151.314106]  [c02348e3] ? rw_verify_area+0x63/0x110
[ 151.314106]  [c0234e7d] vfs_read+0x13d/0x160
[ 151.314106]  [c0234edd] sys_read+0x3d/0x80
[ 151.314106]  [c04caf5f] sysenter_do_call+0x12/0x28
[ 151.314106] Code: 2c 1f c0 8d 4d fc c7 45 fc 00 00 00 00 e8 e1 fe ff ff
8b 45 fc 64 01 05 64 28 6c c0 c9 c3 90 8d
74 26 00 55 89 e5 3e 8d 74 26 00 f7 00 00 c0 00 00 75 17 3e ff 48 10 0f
94 c2 84 d2 75 05 5d c3
[ 151.314106] EIP: [c01f35a8] put_page+0x8/0x40 SS:ESP 0068:ce133da4
[ 151.314106] CR2: 51c39a07
2012 Aug 15 16:01:58 localhost [ 151.314106] Process wget (pid: 387,
ti=ce132000 task=cea92a80 task.ti=ce132000)
[ 151.314106] ---[end trace d015761e7dbf4ff2]---
2012 Aug 15 16:01:58 localhost [ 151.314106] Stack:
2012 Aug 15 16:01:58 localhost [ 151.314106] Call Trace:
2012 Aug 15 16:01:58 localhost [ 151.314106] Code: 2c 1f c0 8d 4d fc c7 45
fc 00 00 00 00 e8 e1 fe ff ff 8b 45 fc
64 01 05 64 28 6c c0 c9 c3 90 8d 74 26 00 55 89 e5 3e 8d 74 26 00 f7 00
00 c0 00 00 75 17 3e ff 48 10 0f 94 c2 84
d2 75 05 5d c3
2012 Aug 15 16:01:58 localhost [ 151.314106] EIP: [c01f35a8]
put_page+0x8/0x40 SS:ESP 0068:ce133da4

The host machines are running qemu-kvm 1.1.1, kernel 3.5.1. Hardware is 2 x
8-core AMD Opteron 6128 and 128GB RAM.

Please let me know if I can provide any more useful information, and as
always, thanks in advance.

[Qemu-devel] [Bug 1034423] [NEW] Guests running OpenIndiana (and relatives) fail to boot on AMD hardware

[Owen Tuz]

Public bug reported:

First observed with OpenSolaris 2009.06, and also applies to the latest
OpenIndiana release.

Version: qemu-kvm 1.1.1

Hardware:

2 x AMD Opteron 6128 8-core processors, 64GB RAM.

These guests boot on equivalent Intel hardware.

To reproduce:

qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc
:99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot
order=dc

I've tested with -vga std and various different emulated CPU types, to
no effect.

What happens:

GRUB loads, and offers multiple boot options, but none work. Some kind
of kernel panic flies by very fast before restarting the VM, and careful
use of the screenshot button reveals that it reads as follows:

panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
rp=fec2b48c add r=0

#df Double fault
pid=0, pc=0xault
pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
cr0: 80050011pg,wp,et,pe cr4:b8pge,pae,pse,de
cr2: 0cr3: ae2f000
  gs:1b0fs:  0   es: 160   ds:  
160
 edi:0  esi:  0 ebp: 0 esp: 
fec2b4c4
 ebx: c0010015 edx:  0 ecx: 0 eax: fec40400
 trp: 8  err:  0 eip: fe800377  cs: 
  158
 efl: 202 usp: fec40090  ss:   160
tss.tss_link: 0x0
tss.tss_esp0:   0x0
tss.tss_ss0: 0x160
tss.tss_esp1:   0x0
tss.tss_ss1:  0x0
tss.tss esp2: 0x0
tss.tss_ss2:  0x0
tss.tss_cr3:   0xae2f000
tss.tss_eip:   0xfec40400
tss.tss_eflags:  0x202
tss.tss_eax:  0xfec40400
tss.tss_ebx:  0xc0010015
tss.tss_ecx:  0xc001
tss.tss_edx:  0x0
tss.tss_esp:  0xfec40090

Warning - stack not written to the dumpbuf
fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)

If there's any more, I haven't managed to catch it.

Solaris 11 does not seem to suffer from the same issue, although the
first message that appears at boot (after the version info) is trap:
Unkown trap type 8 in user mode. Could be related?

As always, thanks in advance and please let me know if I can help to
test, or provide any more information.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1034423

Title:
  Guests running OpenIndiana (and relatives) fail to boot on AMD
  hardware

Status in QEMU:
  New

Bug description:
  First observed with OpenSolaris 2009.06, and also applies to the
  latest OpenIndiana release.

  Version: qemu-kvm 1.1.1

  Hardware:

  2 x AMD Opteron 6128 8-core processors, 64GB RAM.

  These guests boot on equivalent Intel hardware.

  To reproduce:

  qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
  -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
  151a5-live-x86.iso -boot order=dc

  I've tested with -vga std and various different emulated CPU types,
  to no effect.

  What happens:

  GRUB loads, and offers multiple boot options, but none work. Some kind
  of kernel panic flies by very fast before restarting the VM, and
  careful use of the screenshot button reveals that it reads as follows:

  panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
  rp=fec2b48c add r=0

  #df Double fault
  pid=0, pc=0xault
  pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
  cr0: 80050011pg,wp,et,pe cr4:b8pge,pae,pse,de
  cr2: 0cr3: ae2f000
gs:1b0fs:  0   es: 160   
ds:  160
   edi:0  esi:  0 ebp: 0 
esp: fec2b4c4
   ebx: c0010015 edx:  0 ecx: 0 eax: 
fec40400
   trp: 8  err:  0 eip: fe800377  cs:   
158
   efl: 202 usp: fec40090  ss:   160
  tss.tss_link: 0x0
  tss.tss_esp0:   0x0
  tss.tss_ss0: 0x160
  tss.tss_esp1:   0x0
  tss.tss_ss1:  0x0
  tss.tss esp2: 0x0
  tss.tss_ss2:  0x0
  tss.tss_cr3:   0xae2f000
  tss.tss_eip:   0xfec40400
  tss.tss_eflags:  0x202
  tss.tss_eax:  0xfec40400
  tss.tss_ebx:  0xc0010015
  tss.tss_ecx:  0xc001
  tss.tss_edx:  0x0
  tss.tss_esp:  0xfec40090

  Warning - stack not written to the dumpbuf
  fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
  fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
  fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)

  If there's any more, I haven't managed to catch it.

  Solaris 11 does not seem to suffer from the same issue, although the
  first message that appears at boot (after the version info) is trap:
  Unkown trap type 8 in user mode. Could be related?

  As always, thanks in advance and please let me know if I can help to
  test, or provide any more information.

To 

[Qemu-devel] [Bug 1034423] Guests running OpenIndiana (and relatives) fail to boot on AMD hardware

[Owen Tuz]

Reported as a bug at: https://bugs.launchpad.net/qemu/+bug/1034423

First observed with OpenSolaris 2009.06, and also applies to the latest
OpenIndiana release.

Version: qemu-kvm 1.1.1

Hardware:

2 x AMD Opteron 6128 8-core processors, 64GB RAM.

These guests boot on equivalent Intel hardware.

To reproduce:

qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc
:99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot
order=dc

I've tested with -vga std and various different emulated CPU types, to no
effect.

What happens:

GRUB loads, and offers multiple boot options, but none work. Some kind of
kernel panic flies by very fast before restarting the VM, and careful use
of the screenshot button reveals that it reads as follows:

panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
rp=fec2b48c add r=0

#df Double fault
pid=0, pc=0xault
pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
cr0: 80050011pg,wp,et,pe cr4:b8pge,pae,pse,de
cr2: 0cr3: ae2f000
  gs: 1b0 fs: 0 es: 160 ds: 160
 edi: 0 esi: 0 ebp: 0 esp: fec2b4c4
 ebx: c0010015 edx: 0 ecx: 0 eax: fec40400
 trp: 8 err: 0 eip: fe800377 cs: 158
 efl: 202 usp: fec40090 ss: 160
tss.tss_link: 0x0
tss.tss_esp0: 0x0
tss.tss_ss0: 0x160
tss.tss_esp1: 0x0
tss.tss_ss1: 0x0
tss.tss esp2: 0x0
tss.tss_ss2: 0x0
tss.tss_cr3: 0xae2f000
tss.tss_eip: 0xfec40400
tss.tss_eflags: 0x202
tss.tss_eax: 0xfec40400
tss.tss_ebx: 0xc0010015
tss.tss_ecx: 0xc001
tss.tss_edx: 0x0
tss.tss_esp: 0xfec40090

Warning - stack not written to the dumpbuf
fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)

If there's any more, I haven't managed to catch it.

Solaris 11 does not seem to suffer from the same issue, although the first
message that appears at boot (after the version info) is trap: Unkown trap
type 8 in user mode. Could be related?

As always, thanks in advance and please let me know if I can help to test,
or provide any more information.

Thanks,

Owen

Re: [Qemu-devel] [Bug 992067] Re: Windows 2008R2 very slow cold boot when 4GB memory

[Owen Tuz]

We have been experiencing this problem for a while now too, using qemu-kvm 
(currently at 1.1.1). 

Unfortunately, hv_relaxed doesn't seem to fix it. The following command line 
produces the issue:

qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice 
tablet -vnc :99 -monitor stdio -hda
test.img

The hardware consists of dual AMD Opteron 6128 processors (16 cores in total) 
and 64GB of memory. This command line was tested on kernel 3.1.4. 

I've also tested with -no-hpet.

What I have seen is much as described: the memory fills out slowly, and top on 
the host will show the process using
100% on all allocated CPU cores. The most extreme case was a machine which took 
something between 6 and 8 hours to boot.

This seems to be related to the assigned memory, as described, but also the 
number of processor cores (which makes
sense if we believe it's a timing issue?). I have seen slow-booting guests 
improved by switching down to a single or even two cores.

Matthew, I agree that this seems to be linked to the number of VMs running - in 
fact, shutting down other VMs on a dedicated test host caused the machine to 
start booting at a normal speed (with no reboot required).

However, the level of contention is never such that this could be explained by 
the host simply being overcommitted.

If it helps anyone, there's an image of the hard drive I've been using to test 
at:

http://46.20.114.253/

It's 5G of gzip file containing a fairly standard Windows 2008 trial 
installation. Since it's in the trial period, anyone who wants to use it may 
have to re-arm the trial: http://support.microsoft.com/kb/948472 

Please let me know if I can provide any more information, or test anything.

Best wishes,

Owen Tuz