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
peter1.jpg
Description: JPEG image
peter2.jpg
Description: JPEG image
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home
