Sorry,
my config:
kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
memory = 512
shadow_memory = 16
name = "vbxl204"
disk = [ 'phy:/dev/disk/by-id/scsi-350060e800351af00000051af0000000d,hda,w',
'file:/bigvol/installmedia/winxp-en-setup-SP2.iso,hdc:cdrom,r','file:/bigvol/installmedia/winxp-SP1a-SP3-dotnet2.0.iso,hdd:cdrom,r',
]
vif = [ 'mac=00:16:3E:00:02:03,bridge=vlanbr640', ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
boot='dc'
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncunused=1
acpi=1
apic=0
pae=1
usb = 1
usbdevice = 'tablet'
#serial="pty"
Kindest regards,
Peter.
On Wednesday 08 October 2008 12:45:35 Peter Van Biesen wrote:
> Hi,
>
> the windows xp doesn't crash. It runs fine. But rebooting is always kind of a
> gamble - what will be missing ? boot.ini ? ntoskrnl.exe ? or does windows xp
> just want to chkdsk ? I've tried the gplpv drivers, they seem to run but
> switching between gplpv and non-gplpv would break windows completely. If I
> try to change networksettings of the xen network card while in gplpv mode
> windows systematically breaks.
>
> I threw away that windows xp image. I used it to try live migration and this
> does not work - gplpv or not ( I've given up on that ). I now have a freshly
> installed windows xp image running without gplpv and a second image running
> with gplpv drivers.
>
> Without the gplpv drivers, it now runs smoothly but slow for disk io. With
> the drivers, my rdp session stops working every couple of minutes. When I run
> a ping on it, the connection is very very intermittent and sometime stalls or
> drops away. I use dhcp for both the ioemu and the xen network adapter, so it
> should be identical.
>
> 64 bytes from 172.16.6.231: icmp_seq=14 ttl=128 time=0.242 ms
> 64 bytes from 172.16.6.231: icmp_seq=15 ttl=128 time=0.252 ms
> 64 bytes from 172.16.6.231: icmp_seq=16 ttl=128 time=0.273 ms
> 64 bytes from 172.16.6.231: icmp_seq=17 ttl=128 time=0.262 ms
> 64 bytes from 172.16.6.231: icmp_seq=18 ttl=128 time=0.238 ms
> 64 bytes from 172.16.6.231: icmp_seq=19 ttl=128 time=0.261 ms
> 64 bytes from 172.16.6.231: icmp_seq=20 ttl=128 time=0.241 ms
> 64 bytes from 172.16.6.231: icmp_seq=21 ttl=128 time=0.247 ms
> 64 bytes from 172.16.6.231: icmp_seq=22 ttl=128 time=0.238 ms
> 64 bytes from 172.16.6.231: icmp_seq=23 ttl=128 time=5887 ms
> 64 bytes from 172.16.6.231: icmp_seq=24 ttl=128 time=4887 ms
> 64 bytes from 172.16.6.231: icmp_seq=25 ttl=128 time=3887 ms
> 64 bytes from 172.16.6.231: icmp_seq=26 ttl=128 time=2887 ms
> 64 bytes from 172.16.6.231: icmp_seq=27 ttl=128 time=1887 ms
> 64 bytes from 172.16.6.231: icmp_seq=28 ttl=128 time=887 ms
> 64 bytes from 172.16.6.231: icmp_seq=29 ttl=128 time=0.281 ms
> 64 bytes from 172.16.6.231: icmp_seq=30 ttl=128 time=0.252 ms
> 64 bytes from 172.16.6.231: icmp_seq=31 ttl=128 time=0.266 ms
> 64 bytes from 172.16.6.231: icmp_seq=32 ttl=128 time=0.261 ms
> 64 bytes from 172.16.6.231: icmp_seq=33 ttl=128 time=0.273 ms
> 64 bytes from 172.16.6.231: icmp_seq=34 ttl=128 time=0.258 ms
> 64 bytes from 172.16.6.231: icmp_seq=35 ttl=128 time=0.255 ms
> 64 bytes from 172.16.6.231: icmp_seq=36 ttl=128 time=0.247 ms
> 64 bytes from 172.16.6.231: icmp_seq=37 ttl=128 time=0.263 ms
>
> From pcvlf1922.local (172.16.4.70) icmp_seq=129 Destination Host Unreachable
> From pcvlf1922.local (172.16.4.70) icmp_seq=130 Destination Host Unreachable
> From pcvlf1922.local (172.16.4.70) icmp_seq=131 Destination Host Unreachable
> From pcvlf1922.local (172.16.4.70) icmp_seq=132 Destination Host Unreachable
> 64 bytes from 172.16.6.231: icmp_seq=58 ttl=128 time=77914 ms
> From pcvlf1922.local (172.16.4.70) icmp_seq=133 Destination Host Unreachable
> From pcvlf1922.local (172.16.4.70) icmp_seq=134 Destination Host Unreachable
> From pcvlf1922.local (172.16.4.70) icmp_seq=135 Destination Host Unreachable
> 64 bytes from 172.16.6.231: icmp_seq=59 ttl=128 time=76914 ms
> 64 bytes from 172.16.6.231: icmp_seq=60 ttl=128 time=75914 ms
> 64 bytes from 172.16.6.231: icmp_seq=61 ttl=128 time=74914 ms
> 64 bytes from 172.16.6.231: icmp_seq=62 ttl=128 time=73914 ms
> 64 bytes from 172.16.6.231: icmp_seq=63 ttl=128 time=72914 ms
> 64 bytes from 172.16.6.231: icmp_seq=64 ttl=128 time=71914 ms
> 64 bytes from 172.16.6.231: icmp_seq=65 ttl=128 time=70914 ms
> 64 bytes from 172.16.6.231: icmp_seq=66 ttl=128 time=69914 ms
>
> I also am running linux domu's on the same server, they do not have any
> problem whatsoever.
>
> My impression is that xen and windows is still highly experimental and I'm
> running out of time to prove ( to my bosses ) that it can be done. I still
> have to find someone who is running a windows under xen in production ...
>
> We're running 20 dom0's and about 50 linux domU's in production at the moment
> without problems but if one would ask me how to virtualise a windows, I would
> have to advise vmware. From my ( sysadmin ) point of view there are to many
> 'strange things' happening.
>
> Something strange i saw that differs from the linux'es is the tap* devices.
> They tend to change the mac address of the bridge on which they are attached.
>
> vlanbr640 Link encap:Ethernet HWaddr 1a:2d:54:ad:2e:7e
> inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1845367 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:119469265 (113.9 MiB) TX bytes:258 (258.0 B)
>
> On the other bridges, the HWaddr is fe:ff:ff:ff:ff:ff .
>
> Btw, I just rebooted my image with gplpv driver, screenshots in attachment.
>
> Kindest regards,
>
> Peter.
> On Tuesday 07 October 2008 12:39:10 James Harper wrote:
> > > Hi, how are you doing?
> > >
> > > 2008. 10. 7, kedd keltezéssel 10.27-kor Peter Van Biesen ezt írta:
> > > > I'm currently running windows XP without the gplpv drivers.
> > >
> > > Have you installed those drivers? I so, have you ever booted with
> > > the /gplpv option? What is your domU config?
> > >
> >
> > If his system is crashing without the drivers then I have doubts that
> > installing them will make things any better. The only thing they might do
> > is that they might be less likely to cause corruption if the physical
> > server crashes, and I haven't done enough testing to say that with any
> > certainty.
> >
> > James
> >
> >
>
>
>
--
Peter Van Biesen
Sysadmin VAPH
tel: +32 (0) 2 225 85 70
fax: +32 (0) 2 225 85 88
e-mail: peter.vanbiesen@xxxxxxx
PGP: http://www.vaph.be/pgpkeys
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home