Discussion:
Release 0.9.5 of GPL PV Drivers for Windows
(too old to reply)
James Harper
2008-06-01 13:22:44 UTC
Permalink
I've just made my first ever attempt at an Nullsoft installer, so if you
want to try it download "Xen PV Drivers 0.9.5.exe" from
http://www.meadowcourt.org/downloads/

The installer should detect the version of windows you are running and
install the drivers. At the moment you'll need to install the shutdown
monitor service manually, but you can do that from the start menu.

I haven't figured out a way to update the boot.ini (and the vista
equivalent) yet, and I'm a bit reluctant to try it as there is plenty of
potential to break things. I have added some documentation on the use of
bcdedit to the wiki though (you can get to the wiki page from the start
menu, or http://wiki.xensource.com/xenwiki/XenWindowsGplPv), so if
someone can have a look and let me know if there's a better way I'd be
very grateful.

Other than that, I fixed a bug which was stopping the drivers working
for me under windows 2008, so if 2008 or Vista wasn't working previously
you might like to try this version.

I'd still like to hear from anyone who's run disk performance testing
recently... 0.9.3+ might perform a little better...

Thanks

James
Nick Couchman
2008-06-01 14:29:00 UTC
Permalink
James,
Sorry if I missed it earlier, but on version 0.9.2 you mentioned a bug that would essentially lock up the dom0 system for 5 or so minutes if a Windows bug check occurred on a system running the GPL PV drivers. Any word or whether this is fixed or not?

Thanks - Nick

>>> On 2008/06/01 at 07:22, "James Harper" <***@bendigoit.com.au> wrote:
I've just made my first ever attempt at an Nullsoft installer, so if you
want to try it download "Xen PV Drivers 0.9.5.exe" from
http://www.meadowcourt.org/downloads/

The installer should detect the version of windows you are running and
install the drivers. At the moment you'll need to install the shutdown
monitor service manually, but you can do that from the start menu.

I haven't figured out a way to update the boot.ini (and the vista
equivalent) yet, and I'm a bit reluctant to try it as there is plenty of
potential to break things. I have added some documentation on the use of
bcdedit to the wiki though (you can get to the wiki page from the start
menu, or http://wiki.xensource.com/xenwiki/XenWindowsGplPv), so if
someone can have a look and let me know if there's a better way I'd be
very grateful.

Other than that, I fixed a bug which was stopping the drivers working
for me under windows 2008, so if 2008 or Vista wasn't working previously
you might like to try this version.

I'd still like to hear from anyone who's run disk performance testing
recently... 0.9.3+ might perform a little better...

Thanks

James





This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
James Harper
2008-06-02 00:18:48 UTC
Permalink
> James,
> Sorry if I missed it earlier, but on version 0.9.2 you mentioned a bug
> that would essentially lock up the dom0 system for 5 or so minutes if
a
> Windows bug check occurred on a system running the GPL PV drivers.
Any
> word or whether this is fixed or not?

Probably not fixed. I plan to get back to that shortly.

James
James Harper
2008-06-02 02:09:59 UTC
Permalink
> James,
> Sorry if I missed it earlier, but on version 0.9.2 you mentioned a bug
> that would essentially lock up the dom0 system for 5 or so minutes if
a
> Windows bug check occurred on a system running the GPL PV drivers.
Any
> word or whether this is fixed or not?
>

I've just put up 0.9.6 which fixes that problem.

James
Nick Couchman
2008-06-02 12:12:36 UTC
Permalink
Wow - quick work - thanks!!

-Nick

>>> On 2008/06/01 at 20:09, "James Harper" <***@bendigoit.com.au> wrote:
> James,
> Sorry if I missed it earlier, but on version 0.9.2 you mentioned a bug
> that would essentially lock up the dom0 system for 5 or so minutes if
a
> Windows bug check occurred on a system running the GPL PV drivers.
Any
> word or whether this is fixed or not?
>

I've just put up 0.9.6 which fixes that problem.

James



This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Fajar A. Nugraha
2008-06-04 10:54:13 UTC
Permalink
Nick Couchman wrote:
> Wow - quick work - thanks!!
>
> >>> On 2008/06/01 at 20:09, "James Harper"
> <***@bendigoit.com.au> wrote:
>
> I've just put up 0.9.6 which fixes that problem.
>

Hi James,

I just want to say, great work! I tried gplpv 0.9.6 (normal install, no
additional tweaks) on RHEL5.2/xen3.2.1 (xen.org's srpm rebuilt), and I
got these results :

- network transfer domU->dom0 : around 70 Mbps (tested with iperf, no
additional options). This is around 1/10 Linux PV performance.
- disk I/O : around 4 MBps simultaneus read-and-write on the same block
device (load created with dd inside guest, performance measured with
iostat from host). This is around 1/3 Linux PV performance.

Both numbers are lower compared to PV performance, but IMHO it has
reached an "acceptable" level :D Great improvement when compared to
original HVM performance.

Regards,

Fajar
Dustin Henning
2008-06-02 12:56:31 UTC
Permalink
James,
I saw some discussion about xenscsi/pvscsi in last month's archives
(I wasn't a member yet, so I don't have the e-mails to respond to). I
haven't seen anything on the newer version the author was talking about
posting, so I am wondering if it might have been posted to some other list
where you are be a member. Also, I am curious as to whether or not it might
benefit me. I have four Windows domUs, each has its own SATA HD, so I think
I could use those drivers (alongside the GPL PV ones for everything else).
Therefore, with that configuration, I wonder if those drivers wouldn't
provide better performance than using the gpl pv vbd drivers (primarily
because I know you were recently discussing issues with how Windows
interfaces that require your drivers to use double buffering sometimes, and
also because I don't know if the scsi drivers require as much interaction
with the hypervisor). However, I also noticed that everyone who mentioned
the scsi drivers was talking about /dev/sgX (where I am talking about
/dev/sdX), and from what I read, the drivers might really be made primarily
to be useful for non-block devices, so I don't know how ideal they would be
for block performance.
Also, on the GPL PV drivers, I saw mention by a couple people of
their machines taking so long to boot that they gave up (on previous driver
version threads). When I tried 0.8.7, 0.8.9, and 0.9.0, I had that same
experience, and it just occurred to me that it may have been because of the
bug apparently fixed in 0.9.6. However, 0.9.2 worked for me, so I am not
sure if it would stand to reason that there could be any relation. In each
instance where the machine didn't seem to be booting, I could see in VNC
that it looked like it was booting fine (Windows XP boot animation ran
smoothly at normal speed), however, when looking at xm list or xentop, I
could see that the cpu time stalled out at between 7 and 14 seconds (got
there really fast and then just pretty much stopped incrementing) and the
cpu usage for the domU was practically idle (less than 2% which is normal on
all of my XP domUs all the time). I suppose is possible that there was a
bug check when the driver was loading and I just lucked out and didn't
experience that on 0.9.2 (seems like one person who mentioned a similar
experience was above 0.9.2). What do you think? Thanks,
Dustin

-----Original Message-----
From: xen-users-***@lists.xensource.com
[mailto:xen-users-***@lists.xensource.com] On Behalf Of James Harper
Sent: Sunday, June 01, 2008 22:10
To: Nick Couchman; xen-***@lists.xensource.com;
xen-***@lists.xensource.com
Subject: [Xen-users] Release 0.9.6 of GPL PV Drivers for Windows

> James,
> Sorry if I missed it earlier, but on version 0.9.2 you mentioned a bug
> that would essentially lock up the dom0 system for 5 or so minutes if
a
> Windows bug check occurred on a system running the GPL PV drivers.
Any
> word or whether this is fixed or not?
>

I've just put up 0.9.6 which fixes that problem.

James
James Harper
2008-06-03 01:19:02 UTC
Permalink
> James,
> I saw some discussion about xenscsi/pvscsi in last month's
archives
> (I wasn't a member yet, so I don't have the e-mails to respond to). I
> haven't seen anything on the newer version the author was talking
about
> posting, so I am wondering if it might have been posted to some other
list
> where you are be a member. Also, I am curious as to whether or not it
> might
> benefit me. I have four Windows domUs, each has its own SATA HD, so I
> think
> I could use those drivers (alongside the GPL PV ones for everything
else).

If you load the 'sg' module under linux, you'll get a /dev/sgX entry for
each scsi device (sd, st, etc) which is used to be able to send raw scsi
commands to devices.

If you wanted to pass raw disks to domains then pvscsi could do that,
but I can't speak from a performance point of view as I haven't tried
it. There could be less overheads involved... You also wouldn't be able
to boot from them as I don't believe that the HVM bios can boot from raw
scsi disks.

Jun posted the latest pvscsi patches to the xen-devel list on Friday
30th, you should be able to find them in the mailing list archives.

James
Dustin Henning
2008-06-03 14:21:20 UTC
Permalink
-----Original Message-----
From: xen-users-***@lists.xensource.com
[mailto:xen-users-***@lists.xensource.com] On Behalf Of James Harper
Sent: Monday, June 02, 2008 21:19
To: ***@prd-inc.com; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.6 of GPL PV Drivers for Windows

If you load the 'sg' module under linux, you'll get a /dev/sgX entry for
each scsi device (sd, st, etc) which is used to be able to send raw scsi
commands to devices.

If you wanted to pass raw disks to domains then pvscsi could do that,
but I can't speak from a performance point of view as I haven't tried
it. There could be less overheads involved... You also wouldn't be able
to boot from them as I don't believe that the HVM bios can boot from raw
scsi disks.

Jun posted the latest pvscsi patches to the xen-devel list on Friday
30th, you should be able to find them in the mailing list archives.

James

_______________________________________________
Xen-users mailing list
Xen-***@lists.xensource.com
http://lists.xensource.com/xen-users


I knew that one couldn't boot to scsi devices with the xen hvm bios;
in older versions of xen, I passed sda instead of hda to pv guests and I
couldn't do the same to hvm guests because the bios wouldn't boot to them.
I had forgotten, though. That means the performance difference is moot in
my implementation.

I have found a couple of issues in 0.9.6 that I thought I should run
by you. You may already know about them, but the only thing under known
issues in the wiki is "no showstoppers" and I don't know where else such a
list might exist. I suspect you already know about the first issue, but in
case you don't (or it is specific to my environment, this is in F8 with the
latest xen 3.0 from the fedora-updates repo):

-When I boot with /gplpv, xm block-list fails as follows (the command works
fine if I boot up without the /gplpv switch):

$ sudo /usr/sbin/xm block-list 1
Unexpected error: <class 'xml.parsers.expat.ExpatError'>

Please report to xen-***@lists.xensource.com
Traceback (most recent call last):
File "/usr/sbin/xm", line 10, in <module>
main.main(sys.argv)
File "/usr/lib64/python2.5/site-packages/xen/xm/main.py", line 2500, in
main
_, rc = _run_cmd(cmd, cmd_name, args)
File "/usr/lib64/python2.5/site-packages/xen/xm/main.py", line 2524, in
_run_cmd
return True, cmd(args)
File "/usr/lib64/python2.5/site-packages/xen/xm/main.py", line 1970, in
xm_block_list
devs = server.xend.domain.getDeviceSxprs(dom, 'vbd')
File "/usr/lib64/python2.5/xmlrpclib.py", line 1150, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.5/site-packages/xen/util/xmlrpcclient.py", line
118, in __request
response = xmlrpclib.ServerProxy.__request(self, methodname, params)
File "/usr/lib64/python2.5/xmlrpclib.py", line 1440, in __request
verbose=self.__verbose
File "/usr/lib64/python2.5/site-packages/xen/util/xmlrpcclient.py", line
55, in request
request_body, verbose)
File "/usr/lib64/python2.5/xmlrpclib.py", line 1204, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib64/python2.5/xmlrpclib.py", line 1338, in _parse_response
p.feed(response)
File "/usr/lib64/python2.5/xmlrpclib.py", line 547, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 23,
column 16


The second issue may not be related to your drivers, and I suppose
it could be specific to my environment as well:

-In xentop, NETS, NETTX, and NETRX all stay 0 if 'vifname = (whatever)' is
used in the vif section of the config file.
For example: vif = [ 'bridge=eth0, vifname=xm2eth0' ]
If vifname=xm2eth0 is not used on that line, then the aforementioned
counters work.


Also, I have a simple question. I have been a member of this list
since just before your release with the nullsoft installer without seeing
this discussed. I am curious as to whether or not it can be used to upgrade
any/all previous versions (and/or whether it will be able to in the future).
I tried out an uninstall with it, and my machine was not bootable afterwards
(without or with /gplpv), so I am trying to figure out how to try move to
new versions going forward.

Finally, if you want to work on the issues I mentioned above and
need any additional information from me, I'll be glad to provide it.
Likewise, if you want me to try anything I would be willing to give it a
shot depending on exactly what it might be (I am running some production
stuff on this machine as well as some test stuff in spite of your warnings
not to do that). However, FYI, I won't be around much in June. Thanks,
Dustin
James Harper
2008-06-06 01:05:48 UTC
Permalink
That looks fine. I've never tested with 'apic=0', so that could be a problem.

If you can wait a bit longer I'll be putting up a new binary release in the next few days which has a fix for a xenbus problem. If it still doesn't work I'll ask for some more info.

James

> -----Original Message-----
> From: Andrej Javoršek [mailto:***@gmail.com]
> Sent: Friday, 6 June 2008 06:44
> To: xen-***@lists.xensource.com
> Cc: James Harper
> Subject: Re: [Xen-users] Release 0.9.6 of GPL PV Drivers for Windows
>
> First sorry if someone got this message twice (I'm hawing problems
> with mail).
>
> Hello!
> That is my domU config (OpenSolaris is normaly using xml version from
> virt-install, but old stile also works).
> ==========
> disk = [ 'phy:/dev/zvol/dsk/p4/w2k3r2s,hdc,w']
>
> memory = 1024
> name = "w2k3r2s"
> kernel = "/usr/lib/xen/boot/hvmloader"
> builder='hvm'
> vif = [ 'type=ioemu, mac=00:14:b1:ab:e2:b4, bridge=nge0' ]
>
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'preserve'
>
> boot='c'
> vnc=1
> vnclisten="0.0.0.0"
> vncpasswd='secret'
> vncunused=0
> vncdisplay=3
> apic=0
> usb=1
> localtime=1
> usbdevice="tablet"
> device_model = '/usr/lib/xen/bin/qemu-dm'
> =========
>
> I'm running Windows 2003r2 sp2 32bit + latest updates on 64bit Dom0.
>
>
> Regards
> Andrej
> On 5.6.2008, at 1:40, James Harper wrote:
>
> >> Hello,
> >> James and others...
> >> I'm trying to use your PV drivers under OpenSolaris 2008.5 and I got
> >> boot drive inaccessible error.
> >> I haven't done lot of digging yet but are those drivers somehow bound
> >> to linux dom0 or just xen?
> >> OpenSolaris is using Xen 3.1.2 and the drivers are version 0.9.6.
> >>
> >
> > Provided that your OpenSolaris Dom0 presents the same configuration
> > on xenbus then I don't see any reason why it wouldn't work. I can't
> > think of anything that would absolutely depend on Linux being the
> > Dom0 OS.
> >
> > I have just fixed a bug which was causing the trailing null byte to
> > be appended to xenbus values, but I can't think that that will make
> > any difference.
> >
> > Can you send me your DomU config file?
> >
> > James
Andrej Javoršek
2008-06-04 19:30:58 UTC
Permalink
Hello,
James and others...
I'm trying to use your PV drivers under OpenSolaris 2008.5 and I got
boot drive inaccessible error BSOD.
I haven't done lot of digging yet but are those drivers somehow bound
to linux dom0 or should they work just on Xen?
OpenSolaris is using Xen 3.1.2 and the drivers are version 0.9.6.

Regards
Andrej Javoršek

BTW: Sorry James to send you this directly to you first time instead
of list...


On 2.6.2008, at 4:09, James Harper wrote:

>> James,
>> Sorry if I missed it earlier, but on version 0.9.2 you mentioned a
>> bug
>> that would essentially lock up the dom0 system for 5 or so minutes if
> a
>> Windows bug check occurred on a system running the GPL PV drivers.
> Any
>> word or whether this is fixed or not?
>>
>
> I've just put up 0.9.6 which fixes that problem.
>
> James
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-***@lists.xensource.com
> http://lists.xensource.com/xen-users
Andrej Javoršek
2008-06-05 20:43:39 UTC
Permalink
First sorry if someone got this message twice (I'm hawing problems
with mail).

Hello!
That is my domU config (OpenSolaris is normaly using xml version from
virt-install, but old stile also works).
==========
disk = [ 'phy:/dev/zvol/dsk/p4/w2k3r2s,hdc,w']

memory = 1024
name = "w2k3r2s"
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
vif = [ 'type=ioemu, mac=00:14:b1:ab:e2:b4, bridge=nge0' ]

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'preserve'

boot='c'
vnc=1
vnclisten="0.0.0.0"
vncpasswd='secret'
vncunused=0
vncdisplay=3
apic=0
usb=1
localtime=1
usbdevice="tablet"
device_model = '/usr/lib/xen/bin/qemu-dm'
=========

I'm running Windows 2003r2 sp2 32bit + latest updates on 64bit Dom0.


Regards
Andrej
On 5.6.2008, at 1:40, James Harper wrote:

>> Hello,
>> James and others...
>> I'm trying to use your PV drivers under OpenSolaris 2008.5 and I got
>> boot drive inaccessible error.
>> I haven't done lot of digging yet but are those drivers somehow bound
>> to linux dom0 or just xen?
>> OpenSolaris is using Xen 3.1.2 and the drivers are version 0.9.6.
>>
>
> Provided that your OpenSolaris Dom0 presents the same configuration
> on xenbus then I don't see any reason why it wouldn't work. I can't
> think of anything that would absolutely depend on Linux being the
> Dom0 OS.
>
> I have just fixed a bug which was causing the trailing null byte to
> be appended to xenbus values, but I can't think that that will make
> any difference.
>
> Can you send me your DomU config file?
>
> James
Geoff Wiener
2008-06-01 18:18:04 UTC
Permalink
James;



While educating myself in the fine art of Xen I have been lurking on the
list and paying close attention to your incredible drivers. I spent
some time today doing exactly what you asked for, disk performance
testing with and without your PV drivers, so I thought I would share my
results with you and the list along with an interesting observation. I
hope you find this useful and have some ideas on what might be going
wrong. Also, I would like to contribute to Xen in general and this is
an area where I feel I am able to offer some assistance. If there is
anything in particular that you would like me to test in more detail or
if you need any more information please let me know and I will do my
best to make the time to work with you on this. I have a rather large
"Windows" estate running on various Hypervisors so I can probably come
up with just about any configuration you want. My current test
configuration is as follows:



Dell Poweredge 1950, Dual 2.0 Ghz 5400 series Intel Procs , Perc 5i, 2 *
SATA 750GB (RAID 1 - WB Cache Enabled in bios and Dom0), 16GB RAM. All
the BIOS' are one version out of date but there are no major bugs in any
of it compelling me to update.



Xen 3.2.1 compiled from source



Dom0 is Centos 5.1



DomU's are on the local storage for testing purposes, an LVM root
partition (default Centos Installation). The only DomU's running on the
machine are the ones mentioned here for these tests and tests were
carried out on one DomU at a time.



All DomU's are fresh installations of: Windows Server 2003, Standard,
R2 SP2 <No windows updates>



I've attached the iometer configuration that I used.



Observation:



I have observed a possible incompatibility between QCOW image files and
the PV drivers. If I create a DomU with the above spec using an image
file created using dd, for example:



dd if=/dev/zero of=guest_disk_sparse.img bs=1k seek=8192k count=1



Then the drivers work fine.



If I create the image file using:



qemu-img create -f qcow2 giest_disk_qcow.qcow 8G



I get a BSOD.. I can send you a pretty screen shot if you like. And
depending on my "disk" line in the HVM config I get the BSOD at
different times. Tap:aio bsods early in the boot and tap:qcow bsods
quite late.



I double checked these results with two fresh machines, one running PV
0.9.1 and the other 0.9.5 just to be sure but it would be great if
someone could double check my work?



Obviously I would prefer performance and stability over the
functionality that the QCow disks give me but if this is an easy fix it
would be great to have it all.





IOMETER Performance Results (see config attached)





Xen 3.2.1

No Tools

Xen 3.2.1

PV 0.95

Xen 3.2.1

PV 0.9.1

Xen 3.2.1

PV 0.9.5

Machine Name

Qcow1

Qcow

W2K3

RAW

Image Type

QCOW2

QCOW2

RAW

RAW

MAX IO's









Total I/O's per second

1801.43

BSOD

4385.78

16330.33

Total MBs per Second

0.88

2.14

7.97

Average I/O response Time

4.4096

1.8225

0.4890

MAX Throughput









Total I/O's per second

576.76

1446.27

547.64

Total MBs per Second

36.05

90.39

34.23

Average I/O response Time

13.8607

5.5269

14.5923

RealLife









Total I/O's per second

404.61

6763.00

610.42

Total MBs per Second

0.79

13.21

1.19

Average I/O response Time

19.7471

1.1815

13.0836



Best Regards



Geoff Wiener
Ryan Burke
2008-06-01 18:55:37 UTC
Permalink
> James;
>
>
>
> While educating myself in the fine art of Xen I have been lurking on the
> list and paying close attention to your incredible drivers. I spent
> some time today doing exactly what you asked for, disk performance
> testing with and without your PV drivers, so I thought I would share my
> results with you and the list along with an interesting observation. I
> hope you find this useful and have some ideas on what might be going
> wrong. Also, I would like to contribute to Xen in general and this is
> an area where I feel I am able to offer some assistance. If there is
> anything in particular that you would like me to test in more detail or
> if you need any more information please let me know and I will do my
> best to make the time to work with you on this. I have a rather large
> "Windows" estate running on various Hypervisors so I can probably come
> up with just about any configuration you want. My current test
> configuration is as follows:
>
>
>
> Dell Poweredge 1950, Dual 2.0 Ghz 5400 series Intel Procs , Perc 5i, 2 *
> SATA 750GB (RAID 1 - WB Cache Enabled in bios and Dom0), 16GB RAM. All
> the BIOS' are one version out of date but there are no major bugs in any
> of it compelling me to update.
>
>
>
> Xen 3.2.1 compiled from source
>
>
>
> Dom0 is Centos 5.1
>
>
>
> DomU's are on the local storage for testing purposes, an LVM root
> partition (default Centos Installation). The only DomU's running on the
> machine are the ones mentioned here for these tests and tests were
> carried out on one DomU at a time.
>
>
>
> All DomU's are fresh installations of: Windows Server 2003, Standard,
> R2 SP2 <No windows updates>
>
>
>
> I've attached the iometer configuration that I used.
>
>
>
> Observation:
>
>
>
> I have observed a possible incompatibility between QCOW image files and
> the PV drivers. If I create a DomU with the above spec using an image
> file created using dd, for example:
>
>
>
> dd if=/dev/zero of=guest_disk_sparse.img bs=1k seek=8192k count=1
>
>
>
> Then the drivers work fine.
>
>
>
> If I create the image file using:
>
>
>
> qemu-img create -f qcow2 giest_disk_qcow.qcow 8G
>
>
>
> I get a BSOD.. I can send you a pretty screen shot if you like. And
> depending on my "disk" line in the HVM config I get the BSOD at
> different times. Tap:aio bsods early in the boot and tap:qcow bsods
> quite late.
>
>
>
> I double checked these results with two fresh machines, one running PV
> 0.9.1 and the other 0.9.5 just to be sure but it would be great if
> someone could double check my work?
>
>
>
> Obviously I would prefer performance and stability over the
> functionality that the QCow disks give me but if this is an easy fix it
> would be great to have it all.
>
>
>
>
>
> IOMETER Performance Results (see config attached)
>
>
>
>
>
> Xen 3.2.1
>
> No Tools
>
> Xen 3.2.1
>
> PV 0.95
>
> Xen 3.2.1
>
> PV 0.9.1
>
> Xen 3.2.1
>
> PV 0.9.5
>
> Machine Name
>
> Qcow1
>
> Qcow
>
> W2K3
>
> RAW
>
> Image Type
>
> QCOW2
>
> QCOW2
>
> RAW
>
> RAW
>
> MAX IO's
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 1801.43
>
> BSOD
>
> 4385.78
>
> 16330.33
>
> Total MBs per Second
>
> 0.88
>
> 2.14
>
> 7.97
>
> Average I/O response Time
>
> 4.4096
>
> 1.8225
>
> 0.4890
>
> MAX Throughput
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 576.76
>
> 1446.27
>
> 547.64
>
> Total MBs per Second
>
> 36.05
>
> 90.39
>
> 34.23
>
> Average I/O response Time
>
> 13.8607
>
> 5.5269
>
> 14.5923
>
> RealLife
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 404.61
>
> 6763.00
>
> 610.42
>
> Total MBs per Second
>
> 0.79
>
> 13.21
>
> 1.19
>
> Average I/O response Time
>
> 19.7471
>
> 1.1815
>
> 13.0836
>
>
>
> Best Regards
>
>
>
> Geoff Wiener


Geoff,

Is there anyway you could reformat those test results? I am having a very
hard time following what the actual results are for each test.

Thanks,
Ryan
Geoff Wiener
2008-06-01 19:39:40 UTC
Permalink
Hi Ryan;

Sorry about that, it was my first post and I incorrectly assumed the
email would get distributed as HTML. Instead of trying to format that
in ASCII, I've attached a .jpg of the table.

G

-----Original Message-----
From: xen-users-***@lists.xensource.com
[mailto:xen-users-***@lists.xensource.com] On Behalf Of Ryan Burke
Sent: 01 June 2008 7:56 PM
To: xen-***@lists.xensource.com
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> James;
>
>
>
> While educating myself in the fine art of Xen I have been lurking on
the
> list and paying close attention to your incredible drivers. I spent
> some time today doing exactly what you asked for, disk performance
> testing with and without your PV drivers, so I thought I would share
my
> results with you and the list along with an interesting observation.
I
> hope you find this useful and have some ideas on what might be going
> wrong. Also, I would like to contribute to Xen in general and this is
> an area where I feel I am able to offer some assistance. If there is
> anything in particular that you would like me to test in more detail
or
> if you need any more information please let me know and I will do my
> best to make the time to work with you on this. I have a rather large
> "Windows" estate running on various Hypervisors so I can probably come
> up with just about any configuration you want. My current test
> configuration is as follows:
>
>
>
> Dell Poweredge 1950, Dual 2.0 Ghz 5400 series Intel Procs , Perc 5i, 2
*
> SATA 750GB (RAID 1 - WB Cache Enabled in bios and Dom0), 16GB RAM.
All
> the BIOS' are one version out of date but there are no major bugs in
any
> of it compelling me to update.
>
>
>
> Xen 3.2.1 compiled from source
>
>
>
> Dom0 is Centos 5.1
>
>
>
> DomU's are on the local storage for testing purposes, an LVM root
> partition (default Centos Installation). The only DomU's running on
the
> machine are the ones mentioned here for these tests and tests were
> carried out on one DomU at a time.
>
>
>
> All DomU's are fresh installations of: Windows Server 2003, Standard,
> R2 SP2 <No windows updates>
>
>
>
> I've attached the iometer configuration that I used.
>
>
>
> Observation:
>
>
>
> I have observed a possible incompatibility between QCOW image files
and
> the PV drivers. If I create a DomU with the above spec using an image
> file created using dd, for example:
>
>
>
> dd if=/dev/zero of=guest_disk_sparse.img bs=1k seek=8192k count=1
>
>
>
> Then the drivers work fine.
>
>
>
> If I create the image file using:
>
>
>
> qemu-img create -f qcow2 giest_disk_qcow.qcow 8G
>
>
>
> I get a BSOD.. I can send you a pretty screen shot if you like. And
> depending on my "disk" line in the HVM config I get the BSOD at
> different times. Tap:aio bsods early in the boot and tap:qcow bsods
> quite late.
>
>
>
> I double checked these results with two fresh machines, one running PV
> 0.9.1 and the other 0.9.5 just to be sure but it would be great if
> someone could double check my work?
>
>
>
> Obviously I would prefer performance and stability over the
> functionality that the QCow disks give me but if this is an easy fix
it
> would be great to have it all.
>
>
>
>
>
> IOMETER Performance Results (see config attached)
>
>
>
>
>
> Xen 3.2.1
>
> No Tools
>
> Xen 3.2.1
>
> PV 0.95
>
> Xen 3.2.1
>
> PV 0.9.1
>
> Xen 3.2.1
>
> PV 0.9.5
>
> Machine Name
>
> Qcow1
>
> Qcow
>
> W2K3
>
> RAW
>
> Image Type
>
> QCOW2
>
> QCOW2
>
> RAW
>
> RAW
>
> MAX IO's
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 1801.43
>
> BSOD
>
> 4385.78
>
> 16330.33
>
> Total MBs per Second
>
> 0.88
>
> 2.14
>
> 7.97
>
> Average I/O response Time
>
> 4.4096
>
> 1.8225
>
> 0.4890
>
> MAX Throughput
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 576.76
>
> 1446.27
>
> 547.64
>
> Total MBs per Second
>
> 36.05
>
> 90.39
>
> 34.23
>
> Average I/O response Time
>
> 13.8607
>
> 5.5269
>
> 14.5923
>
> RealLife
>
>
>
>
>
>
>
>
>
> Total I/O's per second
>
> 404.61
>
> 6763.00
>
> 610.42
>
> Total MBs per Second
>
> 0.79
>
> 13.21
>
> 1.19
>
> Average I/O response Time
>
> 19.7471
>
> 1.1815
>
> 13.0836
>
>
>
> Best Regards
>
>
>
> Geoff Wiener


Geoff,

Is there anyway you could reformat those test results? I am having a
very
hard time following what the actual results are for each test.

Thanks,
Ryan
James Harper
2008-06-01 23:39:53 UTC
Permalink
What bit width are you running (32 or 64)?

> I get a BSOD.. I can send you a pretty screen shot if you like. And
> depending on my "disk" line in the HVM config I get the BSOD at
different
> times. Tap:aio bsods early in the boot and tap:qcow bsods quite late.

Yes please to the screen shot, or at least give me the BSoD numbers.

I'd also appreciate a copy of the 'disk=' lines in your config, and the
output of xenstore-ls /local/domain/<id>/device/vbd, eg 'xenstore-ls
/local/domain/198/device/vbd'. In that output there will be a 'backend='
line, I'd like to see the output of xenstore-ls on that too.

>
> IOMETER Performance Results (see config attached)
>

Well... that's a bit disappointing. I was hoping to see much better
performance but your results seem to indicate worse performance than
with the qemu drivers.

One thing that I've found is that Windows will give scsiport drivers
buffers on almost any alignment, especially for small requests (<
PAGE_SIZE). If that happens, we have to double buffer the requests and
there will be a fairly major performance hit. This happens very rarely
on my test machines but others could be a bit different...

The drivers will complain about this misalignment via debug output, can
you also try running the tests whilst also running 'debugview' from
sysinternals.com?

Thanks

James
Geoff Wiener
2008-06-02 08:48:40 UTC
Permalink
Hi James;

Sorry to be the bearer of bad news on that one...

> What bit width are you running (32 or 64)?

W2K3 SP2 R2 32 bit - I will try 64 bit next and post the results.

> Yes please to the screen shot, or at least give me the BSoD numbers.

Screen shot attached.

> a copy of the 'disk=' lines in your config

For the machine that BSODs
disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w' ]
or
disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w',
'file:/isorep/disc1.iso,hdc:cdrom,r' ]

> output of xenstore-ls /local/domain/<id>/device/vbd

768= ""
backend-id = "0"
virtual-device = "768"
device-type = "disk"
state = "1
backend = "/local/domain/0/backend/tap/52/768"

>In that output there will be a 'backend=' line, I'd like to see the
output of xenstore-ls on that too.

Unfortunately I can't get any output from that.. for example..

xenstore-ls /local/domain0/backend/tap/52/768
or
xenstore-ls /local/domain0/backend/tap/52/768/
or
xenstore-ls /local/domain0/backend/tap/52/

I tried a few variations of the command with no success. I did not
notice in xenstore-ls (alone with no args) that the device-model =
"/usr/lib64/xen/bin/qemu-dm".. I don't know if that's relevant or not...

> can you also try running the tests whilst also running 'debugview'
from sysinternals.com?

With debugview running I selected "capture kernel, capture win32 &
passthrough" and ran the iometer test on the machine with the 0.9.5
drivers (RAW).
The log is attached.

With regards to the "stop" messages, I did some digging and found the
following list of "stop-messages".

http://www.updatexp.com/stop-messages.html

0x0000007b seems about right "inaccessible boot device". I couldn't
find any info on the next one (oxf885ea98) but the third one, oxc0000034

http://www.neowin.net/forum/lofiversion/index.php/t512632.html

Is discussed at the above URL and has to do with .net framework. I know
you use this for the shutdown scripts so I wondered if that was
meaningful?

I will try to make some time to install a 64bit W2K3 R2 later.

Lastly - what is the etiquette on cross posting to both user and devel
lists like this? I do not subscribe to the devel list? Perhaps I
should if I am going to post to it? I just hit reply all... Thanks.

Best Regards

Geoff


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 02 June 2008 12:40 AM
To: Geoff Wiener; xen-***@lists.xensource.com;
xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

What bit width are you running (32 or 64)?

> I get a BSOD.. I can send you a pretty screen shot if you like. And
> depending on my "disk" line in the HVM config I get the BSOD at
different
> times. Tap:aio bsods early in the boot and tap:qcow bsods quite late.

Yes please to the screen shot, or at least give me the BSoD numbers.

I'd also appreciate a copy of the 'disk=' lines in your config, and the
output of xenstore-ls /local/domain/<id>/device/vbd, eg 'xenstore-ls
/local/domain/198/device/vbd'. In that output there will be a 'backend='
line, I'd like to see the output of xenstore-ls on that too.

>
> IOMETER Performance Results (see config attached)
>

Well... that's a bit disappointing. I was hoping to see much better
performance but your results seem to indicate worse performance than
with the qemu drivers.

One thing that I've found is that Windows will give scsiport drivers
buffers on almost any alignment, especially for small requests (<
PAGE_SIZE). If that happens, we have to double buffer the requests and
there will be a fairly major performance hit. This happens very rarely
on my test machines but others could be a bit different...

The drivers will complain about this misalignment via debug output, can
you also try running the tests whilst also running 'debugview' from
sysinternals.com?

Thanks

James
James Harper
2008-06-02 10:18:15 UTC
Permalink
> > Yes please to the screen shot, or at least give me the BSoD numbers.
>
> Screen shot attached.

As you say below, 0x7B is a 'can't find boot device' error.

> > a copy of the 'disk=' lines in your config
>
> For the machine that BSODs
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w' ]
> or
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w',
> 'file:/isorep/disc1.iso,hdc:cdrom,r' ]
>
> > output of xenstore-ls /local/domain/<id>/device/vbd
>
> 768= ""
> backend-id = "0"
> virtual-device = "768"
> device-type = "disk"
> state = "1
> backend = "/local/domain/0/backend/tap/52/768"
>
> >In that output there will be a 'backend=' line, I'd like to see the
> output of xenstore-ls on that too.
>
> Unfortunately I can't get any output from that.. for example..
>
> xenstore-ls /local/domain0/backend/tap/52/768
> or
> xenstore-ls /local/domain0/backend/tap/52/768/
> or
> xenstore-ls /local/domain0/backend/tap/52/

All your examples above say 'domain0' instead of 'domain/0'. Could that
be the problem or did you just make a typo in copying it into the email?

If that doesn't work, just do xenstore-ls /local/domain/0 and tell me
what the domain number is and I'll figure it out from there.

Another thing you could do is to boot with a file: block device, fire up
debugview, and then do a 'xm block-attach' to add the tap device at
runtime and see what debugview says.

I might have a go at using tap too to test it.

> With debugview running I selected "capture kernel, capture win32 &
> passthrough" and ran the iometer test on the machine with the 0.9.5
> drivers (RAW). The log is attached.

Hmmm... no evidence of unaligned buffer access. The queue only seems to
get to a maximum of 8 requests though during the tests which is a bit
strange.

> Lastly - what is the etiquette on cross posting to both user and devel
> lists like this? I do not subscribe to the devel list? Perhaps I
> should if I am going to post to it? I just hit reply all... Thanks.

Not sure... maybe we'll stick to -users for now just to be safe.

James
Geoff Wiener
2008-06-02 11:21:50 UTC
Permalink
Hi James;

>All your examples above say 'domain0' instead of 'domain/0'. Could that
be the problem or did you just make a typo in copying it into the email?

You are right, my bad - I was typing the command wrong - it should be
domain/0. The output you want is:

domain = "qcow"
frontend = "/local/domain/75/device/vbd/768"
uuid = "b01d6f19-e818-f976-a284-ed9a3097d857"
dev = "hda"
state = "2"
params = "qcow:/xenimages/w2k3/w2k3.qcow"
mode = "w"
online = "1"
frontend-id = "75"
type = "tap"
hotplug-status = "connected"

I will have a look at debugview next.

Cheers

G


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 02 June 2008 11:18 AM
To: Geoff Wiener; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> > Yes please to the screen shot, or at least give me the BSoD numbers.
>
> Screen shot attached.

As you say below, 0x7B is a 'can't find boot device' error.

> > a copy of the 'disk=' lines in your config
>
> For the machine that BSODs
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w' ]
> or
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w',
> 'file:/isorep/disc1.iso,hdc:cdrom,r' ]
>
> > output of xenstore-ls /local/domain/<id>/device/vbd
>
> 768= ""
> backend-id = "0"
> virtual-device = "768"
> device-type = "disk"
> state = "1
> backend = "/local/domain/0/backend/tap/52/768"
>
> >In that output there will be a 'backend=' line, I'd like to see the
> output of xenstore-ls on that too.
>
> Unfortunately I can't get any output from that.. for example..
>
> xenstore-ls /local/domain0/backend/tap/52/768
> or
> xenstore-ls /local/domain0/backend/tap/52/768/
> or
> xenstore-ls /local/domain0/backend/tap/52/

All your examples above say 'domain0' instead of 'domain/0'. Could that
be the problem or did you just make a typo in copying it into the email?

If that doesn't work, just do xenstore-ls /local/domain/0 and tell me
what the domain number is and I'll figure it out from there.

Another thing you could do is to boot with a file: block device, fire up
debugview, and then do a 'xm block-attach' to add the tap device at
runtime and see what debugview says.

I might have a go at using tap too to test it.

> With debugview running I selected "capture kernel, capture win32 &
> passthrough" and ran the iometer test on the machine with the 0.9.5
> drivers (RAW). The log is attached.

Hmmm... no evidence of unaligned buffer access. The queue only seems to
get to a maximum of 8 requests though during the tests which is a bit
strange.

> Lastly - what is the etiquette on cross posting to both user and devel
> lists like this? I do not subscribe to the devel list? Perhaps I
> should if I am going to post to it? I just hit reply all... Thanks.

Not sure... maybe we'll stick to -users for now just to be safe.

James
James Harper
2008-06-02 11:59:01 UTC
Permalink
> Hi James;
>
> >All your examples above say 'domain0' instead of 'domain/0'. Could
that
> be the problem or did you just make a typo in copying it into the
email?
>
> You are right, my bad - I was typing the command wrong - it should be
> domain/0. The output you want is:
>
> domain = "qcow"
> frontend = "/local/domain/75/device/vbd/768"
> uuid = "b01d6f19-e818-f976-a284-ed9a3097d857"
> dev = "hda"
> state = "2"
> params = "qcow:/xenimages/w2k3/w2k3.qcow"
> mode = "w"
> online = "1"
> frontend-id = "75"
> type = "tap"
> hotplug-status = "connected"
>
> I will have a look at debugview next.
>

Thanks. I had a go myself but I'm using Debian, and
CONFIG_XEN_BLKDEV_TAP is not enabled in the Debian kernels so I'm stuck
without blktap...

James
Geoff Wiener
2008-06-02 22:56:12 UTC
Permalink
Hi James;

Hopefully I am now the bearer of good news. After our last volley I
understood that you have not been testing your drivers with blktap (as
it is not compiled in your Debian kernel).

So I decided to run the tests again using:

disk = [ 'file:/xenimages/w2k3/pv.img,hda,w']

The difference was astounding! Have a look at the attached .jpg. The
column in purple is configured as above. The performance kills
everything else so far. Then I started thinking about the disk line
itself From what I understand, the reason we specify "hda" for HVM
guests is that until your drivers came along (in the GPL world) HVM
guests did not have support for xvd devices. I'm going to quote from a
book so hopefully this complete reference covers me off: (Great book
BTW:)

Matthews Jeanna, N. 2008. Using Prebuilt Guest Images: Introduction to
DomU guests, Running Xen, A Hands-On Guide to the Art of Virtualization.
Prentice Hall

"The xvd devices interface allows the Xen guest to understand that it
has virtual disks instead of native hardware. The xvd interface
exploits this knowledge to achieve better performance.<snip>: With HVM
guests that do not have paravirtual block device drivers installed, you
still need to use the hd (IDE) and sd (SCS) disks for the DOmU, because,
" by default, HVM guests do not ahve support for xvd devices.

So with that bit of information I went ahead and modified my disk line
as follows:

disk = [ 'file:/xenimages/w2k3/pv.img,xvda,w']

and then ran the tests again. A side note, when the DomU booted it
PnP'ed your Xen Block Device Driver again, I thought that in itself was
interesting. The column in red details the performance after changing
the disk line. You will see that in some cases the performance was
about the same but in others there was a massive improvement. Have a
look, in particular, at the new section I added called "Heavy Write". I
captured this particular workload from a naughty database application
that we host for one of our customers. The best performance that I have
been able to achieve for that particular app, using a very high spec SAN
is detailed in the column to the right labelled "SAN".

The next logical test was to try to use the blktap driver again. No joy
- BSDO city. Just so I am clear in my understanding and please remember
I am a complete NooB with regards to Xen, I am under the impression that
the "file:" prefix is "depreciated" and the blktap driver is the
preferred method of connecting to disk files? Is there some official
documentation on this somewhere? And if this is the case, from what I
understand blktap should perform even better than the loopback driver
that file: is using. (at least that has been my experience in other
environments). So if everything I think I understand is true, what can
we do about getting you a Xen 3.2.1 installation with blktap enabled for
you to develop on? I am open to suggestions about how to get you
sorted. For starters, I have recently been through the pain and
suffering of installing on Centos 5.1, I would be happy to share my
installation notes with you.

Congratulations James, configured correctly your drivers are a huge
success!

Best Regards

Geoff


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 02 June 2008 12:59 PM
To: Geoff Wiener; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> Hi James;
>
> >All your examples above say 'domain0' instead of 'domain/0'. Could
that
> be the problem or did you just make a typo in copying it into the
email?
>
> You are right, my bad - I was typing the command wrong - it should be
> domain/0. The output you want is:
>
> domain = "qcow"
> frontend = "/local/domain/75/device/vbd/768"
> uuid = "b01d6f19-e818-f976-a284-ed9a3097d857"
> dev = "hda"
> state = "2"
> params = "qcow:/xenimages/w2k3/w2k3.qcow"
> mode = "w"
> online = "1"
> frontend-id = "75"
> type = "tap"
> hotplug-status = "connected"
>
> I will have a look at debugview next.
>

Thanks. I had a go myself but I'm using Debian, and
CONFIG_XEN_BLKDEV_TAP is not enabled in the Debian kernels so I'm stuck
without blktap...

James
Pasi Kärkkäinen
2008-06-03 07:37:21 UTC
Permalink
On Mon, Jun 02, 2008 at 11:56:12PM +0100, Geoff Wiener wrote:
> Hi James;
>
> Hopefully I am now the bearer of good news. After our last volley I
> understood that you have not been testing your drivers with blktap (as
> it is not compiled in your Debian kernel).
>
> So I decided to run the tests again using:
>
> disk = [ 'file:/xenimages/w2k3/pv.img,hda,w']
>
> The difference was astounding!

You could also try with phy: and use LVM volumes or so..

>
> Congratulations James, configured correctly your drivers are a huge
> success!
>

Congratulations from me too! :)

-- Pasi
Geoff Wiener
2008-06-03 19:53:12 UTC
Permalink
Hi James;

Ok I found some more information

http://wiki.xensource.com/xenwiki/blktap

Finally I did what you asked.

* Created a raw image
* Booted the DomU with file:/raw-image
* used xm block-attach 7 tap:aio:/xenimages/xana/xana.qcow xvdb w
0 to add a "qcow2" disk to the running instance (the same qcow2 image
that causes a BSOD when used as the boot device)
* PnP found new hardware, Welcome to the found new hardware
wizard, "Yes this time only"
* Xen Block Device Driver, Install the software automatically
(recommended)
* Unsigned warning, Continue anyway
* Then at the "please wait while the wizard installs the software,
XenBlock Device Driver (little flying paper from one folder to the other
above the xenvbd.sys To: c:\windows\system32\drivers... went forever.
Eventually I killed "run32dll" and ended the PNP process all the while
debugview sat quietly and didn't report a single thing.

Any ideas?

Thanks


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 02 June 2008 11:18 AM
To: Geoff Wiener; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> > Yes please to the screen shot, or at least give me the BSoD numbers.
>
> Screen shot attached.

As you say below, 0x7B is a 'can't find boot device' error.

> > a copy of the 'disk=' lines in your config
>
> For the machine that BSODs
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w' ]
> or
> disk = [ 'tap:qcow:/xenimages/w2k3/w2k3.cow,hda,w',
> 'file:/isorep/disc1.iso,hdc:cdrom,r' ]
>
> > output of xenstore-ls /local/domain/<id>/device/vbd
>
> 768= ""
> backend-id = "0"
> virtual-device = "768"
> device-type = "disk"
> state = "1
> backend = "/local/domain/0/backend/tap/52/768"
>
> >In that output there will be a 'backend=' line, I'd like to see the
> output of xenstore-ls on that too.
>
> Unfortunately I can't get any output from that.. for example..
>
> xenstore-ls /local/domain0/backend/tap/52/768
> or
> xenstore-ls /local/domain0/backend/tap/52/768/
> or
> xenstore-ls /local/domain0/backend/tap/52/

All your examples above say 'domain0' instead of 'domain/0'. Could that
be the problem or did you just make a typo in copying it into the email?

If that doesn't work, just do xenstore-ls /local/domain/0 and tell me
what the domain number is and I'll figure it out from there.

Another thing you could do is to boot with a file: block device, fire up
debugview, and then do a 'xm block-attach' to add the tap device at
runtime and see what debugview says.

I might have a go at using tap too to test it.

> With debugview running I selected "capture kernel, capture win32 &
> passthrough" and ran the iometer test on the machine with the 0.9.5
> drivers (RAW). The log is attached.

Hmmm... no evidence of unaligned buffer access. The queue only seems to
get to a maximum of 8 requests though during the tests which is a bit
strange.

> Lastly - what is the etiquette on cross posting to both user and devel
> lists like this? I do not subscribe to the devel list? Perhaps I
> should if I am going to post to it? I just hit reply all... Thanks.

Not sure... maybe we'll stick to -users for now just to be safe.

James
Stefan de Konink
2008-06-03 20:06:11 UTC
Permalink
Geoff Wiener schreef:
> * used xm block-attach 7 tap:aio:/xenimages/xana/xana.qcow xvdb w
> 0 to add a "qcow2" disk to the running instance (the same qcow2 image
> that causes a BSOD when used as the boot device)

Does Xen support qcow2?


Stefan
James Harper
2008-06-04 03:46:33 UTC
Permalink
> Hi James;
>
> Ok I found some more information
>
> http://wiki.xensource.com/xenwiki/blktap
>
> Finally I did what you asked.
>
> * Created a raw image
> * Booted the DomU with file:/raw-image
> * used xm block-attach 7 tap:aio:/xenimages/xana/xana.qcow xvdb w
> 0 to add a "qcow2" disk to the running instance (the same qcow2 image
> that causes a BSOD when used as the boot device)
> * PnP found new hardware, Welcome to the found new hardware
> wizard, "Yes this time only"
> * Xen Block Device Driver, Install the software automatically
> (recommended)
> * Unsigned warning, Continue anyway
> * Then at the "please wait while the wizard installs the software,
> XenBlock Device Driver (little flying paper from one folder to the
other
> above the xenvbd.sys To: c:\windows\system32\drivers... went forever.
> Eventually I killed "run32dll" and ended the PNP process all the while
> debugview sat quietly and didn't report a single thing.
>
> Any ideas?
>

Not at this stage no. I compiled in the tap module to work with my
Debian system, but it still doesn't work for me so I can't test at this
point.

The output of debugview might be useful.

James
Geoff Wiener
2008-06-04 12:26:57 UTC
Permalink
Hi James;

There wasn't any output from debugview unfortunately. I have another,
unrelated question for you if you don't mind. I don't know if this is
meant to work or not (supported at this stage) so I thought I would ask.
Is it possible to have more than one file backed disk in a DomU using
your drivers? I tried this using file:/ for two raw image files (not
sparse) and ran into an issue. The first disk works fine and continues
to work in all cases, the second disk, however, appears in Device
Manager in two places "Disk Drives" and SCSI and RAID Controllers and
then under Disk Management. I have tried every available option for
partition type on both basic and dynamic disks and get the same result.
I can create the partition but when I try to format the disk it gets to
100% then complains "Logical Disk Manager: The format did not complete
successfully". It then shows the disk as healthy but it's impossible to
use the partition. It claims that it's still unformatted. I used
diskpart to have a closer look at the disk and interestingly it report:

Disk: Disk1, Status: online, Size, 2039 MB, Free 0B

I have definitely created a 2 GB RAW file in Dom0 and it is not sparse
(confirmed with du-ah).

Is this supposed to work or am I doing something wrong here?

Thanks

Geoff


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 04 June 2008 4:47 AM
To: Geoff Wiener; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> Hi James;
>
> Ok I found some more information
>
> http://wiki.xensource.com/xenwiki/blktap
>
> Finally I did what you asked.
>
> * Created a raw image
> * Booted the DomU with file:/raw-image
> * used xm block-attach 7 tap:aio:/xenimages/xana/xana.qcow xvdb w
> 0 to add a "qcow2" disk to the running instance (the same qcow2 image
> that causes a BSOD when used as the boot device)
> * PnP found new hardware, Welcome to the found new hardware
> wizard, "Yes this time only"
> * Xen Block Device Driver, Install the software automatically
> (recommended)
> * Unsigned warning, Continue anyway
> * Then at the "please wait while the wizard installs the software,
> XenBlock Device Driver (little flying paper from one folder to the
other
> above the xenvbd.sys To: c:\windows\system32\drivers... went forever.
> Eventually I killed "run32dll" and ended the PNP process all the while
> debugview sat quietly and didn't report a single thing.
>
> Any ideas?
>

Not at this stage no. I compiled in the tap module to work with my
Debian system, but it still doesn't work for me so I can't test at this
point.

The output of debugview might be useful.

James
James Harper
2008-06-04 12:53:53 UTC
Permalink
> There wasn't any output from debugview unfortunately. I have another,
> unrelated question for you if you don't mind. I don't know if this is
> meant to work or not (supported at this stage) so I thought I would
ask.
> Is it possible to have more than one file backed disk in a DomU using
> your drivers? I tried this using file:/ for two raw image files (not
> sparse) and ran into an issue. The first disk works fine and
continues
> to work in all cases, the second disk, however, appears in Device
> Manager in two places "Disk Drives" and SCSI and RAID Controllers and
> then under Disk Management. I have tried every available option for
> partition type on both basic and dynamic disks and get the same
result.
> I can create the partition but when I try to format the disk it gets
to
> 100% then complains "Logical Disk Manager: The format did not complete
> successfully". It then shows the disk as healthy but it's impossible
to
> use the partition. It claims that it's still unformatted. I used
> diskpart to have a closer look at the disk and interestingly it
report:
>
> Disk: Disk1, Status: online, Size, 2039 MB, Free 0B
>
> I have definitely created a 2 GB RAW file in Dom0 and it is not sparse
> (confirmed with du-ah).
>
> Is this supposed to work or am I doing something wrong here?
>

No that should work. I have done it before without any problems. I don't
know what to suggest at this stage... are there messages in Event Viewer
that might indicate the problem? What about in the Dom0 logs?

James
jim burns
2008-06-04 21:22:50 UTC
Permalink
On Wednesday June 04 2008 08:53:53 am James Harper wrote:
> > Disk: Disk1, Status: online, Size, 2039 MB, Free 0B
> >
> > I have definitely created a 2 GB RAW file in Dom0 and it is not sparse
> > (confirmed with du-ah).
> >
> > Is this supposed to work or am I doing something wrong here?
>
> No that should work. I have done it before without any problems. I don't
> know what to suggest at this stage... are there messages in Event Viewer
> that might indicate the problem? What about in the Dom0 logs?

Geoff, just to ask the obvious, you did specify 'w' in your disk definition
right? (In your config's disk= line, or on the xm block-attach line.)
Geoff Wiener
2008-06-04 22:19:10 UTC
Permalink
Hi Jim;

Yes definitely - I have tried both hot plugging as well as adding to the
disk line. In every case I specify that the disk should be writable.
It lets me create the partition which should be a write operation, but
then shows the disk as having 0K free space.

I am trying to capture some info on this right now using regmon - (lots
of output). This definitely doesn't work with Windows Server 2003 R2
SP2 Standard 32 bit MVL (Fully updated and RTM). I would be interested
to know if anyone else has this working and if so what version of
Windows they are running? Have you tested this yourself?

Thanks

Geoff


-----Original Message-----
From: xen-users-***@lists.xensource.com
[mailto:xen-users-***@lists.xensource.com] On Behalf Of jim burns
Sent: 04 June 2008 10:23 PM
To: xen-***@lists.xensource.com
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

On Wednesday June 04 2008 08:53:53 am James Harper wrote:
> > Disk: Disk1, Status: online, Size, 2039 MB, Free 0B
> >
> > I have definitely created a 2 GB RAW file in Dom0 and it is not
sparse
> > (confirmed with du-ah).
> >
> > Is this supposed to work or am I doing something wrong here?
>
> No that should work. I have done it before without any problems. I
don't
> know what to suggest at this stage... are there messages in Event
Viewer
> that might indicate the problem? What about in the Dom0 logs?

Geoff, just to ask the obvious, you did specify 'w' in your disk
definition
right? (In your config's disk= line, or on the xm block-attach line.)
jim burns
2008-06-04 22:41:02 UTC
Permalink
On Wednesday June 04 2008 06:19:10 pm Geoff Wiener wrote:
> I am trying to capture some info on this right now using regmon - (lots
> of output).  This definitely doesn't work with Windows Server 2003 R2
> SP2 Standard 32 bit MVL (Fully updated and RTM).  I would be interested
> to know if anyone else has this working and if so what version of
> Windows they are running?  Have you tested this yourself?

I've only done xm block-attach's of disk space in pv domus, and of .isos or
cdrom devs in hvm domus. I might play with this over the weekend. I would
guess you have no problem attaching a previously formatted image, like from a
different domu, and the only problem is attaching an unformatted image? If
that is the case, try creating an image, and using mkfs.ntfs/mkntfs before
mounting. (Like all mkfs operations, use losetup on the image file to get a
loop device to pass to mkntfs, then losetup -d it.) Good luck.
James Harper
2008-06-04 23:19:53 UTC
Permalink
> Hi Jim;
>
> Yes definitely - I have tried both hot plugging as well as adding to
the
> disk line. In every case I specify that the disk should be writable.
> It lets me create the partition which should be a write operation, but
> then shows the disk as having 0K free space.
>

If you partition that disk image, then reboot the DomU, is the disk
image still partitioned when you reboot? What I'm getting it is are
writes going through?

James
James Harper
2008-06-23 10:55:39 UTC
Permalink
This had me confused for a second, until I noticed that I'd received it
before. Did anyone else get this email a second time? On a list like
xen-users and xen-devel that see's a bit of traffic, a month is a long
time so it's a bit confusing when it happens...

The full headers I received are below, but a summary is:

23/6/8 - from smtp2.bendigoit.com.au (my spam filter)
23/6/8 - from vm04-bcn-london.deploy.xenoserver.org
23/6/8 - from localhost
1/6/8 - from 192.168.0.10
1/6/8 - 194.93.132.247

Is this a case of messages being stalled in an approval queue for a long
time, or an error in mail routing somewhere? Or if nobody else got it a
second time then it must be a problem my end, so please let me know!!!

Thanks

James

Microsoft Mail Internet Headers Version 2.0
Received: from smtp2.bendigoit.com.au ([203.16.207.13]) by
mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 23 Jun 2008 20:45:49 +1000
Received: from vm04-bcn-london.deploy.xenoserver.org ([217.147.82.229]
helo=lists.xensource.com)
by smtp2.bendigoit.com.au with esmtp (Exim 4.63)
(envelope-from <xen-devel-***@lists.xensource.com>)
id 1KAjYE-0002vi-2w
for ***@bendigoit.com.au; Mon, 23 Jun 2008 20:45:49
+1000
Received: from localhost ([127.0.0.1] helo=lists.xensource.com)
by host-192-168-0-1-bcn-london with esmtp (Exim 4.50)
id 1KAjYO-00034H-MI; Mon, 23 Jun 2008 10:45:44 +0000
Received: from [192.168.0.10] (helo=lists.xensource.com)
by host-192-168-0-1-bcn-london with esmtp (Exim 4.50)
id 1K2s9W-0008HP-83; Sun, 01 Jun 2008 18:19:34 +0000
Received: from [194.93.132.247] (helo=mail.aenigmacorp.com)
by lists.xensource.com with esmtp (Exim 4.50)
id 1K2s9P-000426-F9; Sun, 01 Jun 2008 18:19:32 +0000
Received: from EXVS01.aenigmacorp.com ([10.10.6.42]) by
mail.aenigmacorp.com
with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Jun 2008 19:18:37
+0100
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Importance: normal
Priority: normal
Content-Type: multipart/mixed;
boundary="----_=_NextPart_001_01C8C413.E8F2D03D"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826
Date: Sun, 1 Jun 2008 19:18:04 +0100
Message-ID:
<***@EXVS01.aenigmacorp.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows
thread-index: AcjEE9VJQfx8Bmo5Qcq0VJYaZvghhQ==
From: "Geoff Wiener" <***@aenigmacorp.com>
To: "James Harper" <***@bendigoit.com.au>,
<xen-***@lists.xensource.com>, <xen-***@lists.xensource.com>
X-OriginalArrivalTime: 01 Jun 2008 18:18:37.0297 (UTC)
FILETIME=[E9060E10:01C8C413]
X-SA-Exim-Connect-IP: 194.93.132.247
X-SA-Exim-Mail-From: ***@aenigmacorp.com
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on (none)
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.1.0
X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200)
X-SA-Exim-Scanned: Yes (on lists.xensource.com)
X-Mailman-Approved-At: Mon, 23 Jun 2008 10:43:49 +0000
Subject: [Xen-devel] [Xen-users] Release 0.9.5 of GPL PV Drivers for
Windows
X-BeenThere: xen-***@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe:
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,

<mailto:xen-devel-***@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-***@lists.xensource.com>
List-Help: <mailto:xen-devel-***@lists.xensource.com?subject=help>
List-Subscribe:
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
<mailto:xen-devel-***@lists.xensource.com?subject=subscribe>
Sender: xen-devel-***@lists.xensource.com
Errors-To: xen-devel-***@lists.xensource.com
X-HELO-Warning: Remote host 217.147.82.229
(vm04-bcn-london.deploy.xenoserver.org) incorrectly presented itself as
lists.xensource.com
X-Spam-Status: No (score 0.3): AWL=0.296, HTML_MESSAGE=0.001,
MIME_HTML_MOSTLY=0.001
Return-Path: xen-devel-***@lists.xensource.com
Gastón Keller
2008-06-23 15:14:57 UTC
Permalink
On Mon, Jun 23, 2008 at 6:55 AM, James Harper
<***@bendigoit.com.au> wrote:
> This had me confused for a second, until I noticed that I'd received it
> before. Did anyone else get this email a second time? On a list like
> xen-users and xen-devel that see's a bit of traffic, a month is a long
> time so it's a bit confusing when it happens...
>
> The full headers I received are below, but a summary is:
>
> 23/6/8 - from smtp2.bendigoit.com.au (my spam filter)
> 23/6/8 - from vm04-bcn-london.deploy.xenoserver.org
> 23/6/8 - from localhost
> 1/6/8 - from 192.168.0.10
> 1/6/8 - 194.93.132.247
>
> Is this a case of messages being stalled in an approval queue for a long
> time, or an error in mail routing somewhere? Or if nobody else got it a
> second time then it must be a problem my end, so please let me know!!!

Today I received various emails from June 5 and alike (many days old).
Some of them possibly (although I'm not sure) repeated.

Gaston
>
> Thanks
>
> James
>
> Microsoft Mail Internet Headers Version 2.0
> Received: from smtp2.bendigoit.com.au ([203.16.207.13]) by
> mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.3959);
> Mon, 23 Jun 2008 20:45:49 +1000
> Received: from vm04-bcn-london.deploy.xenoserver.org ([217.147.82.229]
> helo=lists.xensource.com)
> by smtp2.bendigoit.com.au with esmtp (Exim 4.63)
> (envelope-from <xen-devel-***@lists.xensource.com>)
> id 1KAjYE-0002vi-2w
> for ***@bendigoit.com.au; Mon, 23 Jun 2008 20:45:49
> +1000
> Received: from localhost ([127.0.0.1] helo=lists.xensource.com)
> by host-192-168-0-1-bcn-london with esmtp (Exim 4.50)
> id 1KAjYO-00034H-MI; Mon, 23 Jun 2008 10:45:44 +0000
> Received: from [192.168.0.10] (helo=lists.xensource.com)
> by host-192-168-0-1-bcn-london with esmtp (Exim 4.50)
> id 1K2s9W-0008HP-83; Sun, 01 Jun 2008 18:19:34 +0000
> Received: from [194.93.132.247] (helo=mail.aenigmacorp.com)
> by lists.xensource.com with esmtp (Exim 4.50)
> id 1K2s9P-000426-F9; Sun, 01 Jun 2008 18:19:32 +0000
> Received: from EXVS01.aenigmacorp.com ([10.10.6.42]) by
> mail.aenigmacorp.com
> with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Jun 2008 19:18:37
> +0100
> Content-Transfer-Encoding: 7bit
> Content-Class: urn:content-classes:message
> MIME-Version: 1.0
> Importance: normal
> Priority: normal
> Content-Type: multipart/mixed;
> boundary="----_=_NextPart_001_01C8C413.E8F2D03D"
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826
> Date: Sun, 1 Jun 2008 19:18:04 +0100
> Message-ID:
> <***@EXVS01.aenigmacorp.com>
> X-MS-Has-Attach: yes
> X-MS-TNEF-Correlator:
> Thread-Topic: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows
> thread-index: AcjEE9VJQfx8Bmo5Qcq0VJYaZvghhQ==
> From: "Geoff Wiener" <***@aenigmacorp.com>
> To: "James Harper" <***@bendigoit.com.au>,
> <xen-***@lists.xensource.com>, <xen-***@lists.xensource.com>
> X-OriginalArrivalTime: 01 Jun 2008 18:18:37.0297 (UTC)
> FILETIME=[E9060E10:01C8C413]
> X-SA-Exim-Connect-IP: 194.93.132.247
> X-SA-Exim-Mail-From: ***@aenigmacorp.com
> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on (none)
> X-Spam-Level:
> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE
> autolearn=ham version=3.1.0
> X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200)
> X-SA-Exim-Scanned: Yes (on lists.xensource.com)
> X-Mailman-Approved-At: Mon, 23 Jun 2008 10:43:49 +0000
> Subject: [Xen-devel] [Xen-users] Release 0.9.5 of GPL PV Drivers for
> Windows
> X-BeenThere: xen-***@lists.xensource.com
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
> List-Unsubscribe:
> <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
>
> <mailto:xen-devel-***@lists.xensource.com?subject=unsubscribe>
> List-Post: <mailto:xen-***@lists.xensource.com>
> List-Help: <mailto:xen-devel-***@lists.xensource.com?subject=help>
> List-Subscribe:
> <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
> <mailto:xen-devel-***@lists.xensource.com?subject=subscribe>
> Sender: xen-devel-***@lists.xensource.com
> Errors-To: xen-devel-***@lists.xensource.com
> X-HELO-Warning: Remote host 217.147.82.229
> (vm04-bcn-london.deploy.xenoserver.org) incorrectly presented itself as
> lists.xensource.com
> X-Spam-Status: No (score 0.3): AWL=0.296, HTML_MESSAGE=0.001,
> MIME_HTML_MOSTLY=0.001
> Return-Path: xen-devel-***@lists.xensource.com
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-***@lists.xensource.com
> http://lists.xensource.com/xen-users
>



--
La única verdad es la realidad.
jim burns
2008-06-23 21:19:46 UTC
Permalink
On Monday June 23 2008 06:55:39 am James Harper wrote:
> This had me confused for a second, until I noticed that I'd received it
> before. Did anyone else get this email a second time? On a list like
> xen-users and xen-devel that see's a bit of traffic, a month is a long
> time so it's a bit confusing when it happens...
[...]
> Is this a case of messages being stalled in an approval queue for a long
> time, or an error in mail routing somewhere? Or if nobody else got it a
> second time then it must be a problem my end, so please let me know!!!

I rec'd some 30 old messages today. Remember when Stephen Spector apologized
for the mailing list being turned off because the hoster hadn't been paid?
Before that, I used to get old/duplicate emails every Monday. (Some I did
remember, some I didn't.) This is the first time since the apology that this
has happened, at least noticeably so.
Evan Miller
2008-06-23 23:38:50 UTC
Permalink
Lists seem to be down often.
It took my original message 6 days or so to get through (I mistakenly
reposted 2x after that...sorry it's my first experience with the mailing
list).
The search feature (for this mailing list) is down for many hours every
day...
Then today and yesterday I got emails from as far back as 22 days ago
(up to 3 weeks before I signed up for the mailing list) in my inbox.
I think lots of issues may be slipping through the cracks because of this.


Xenophan
(AKA Evan Miller)




jim burns wrote:
> On Monday June 23 2008 06:55:39 am James Harper wrote:
>
>> This had me confused for a second, until I noticed that I'd received it
>> before. Did anyone else get this email a second time? On a list like
>> xen-users and xen-devel that see's a bit of traffic, a month is a long
>> time so it's a bit confusing when it happens...
>>
> [...]
>
>> Is this a case of messages being stalled in an approval queue for a long
>> time, or an error in mail routing somewhere? Or if nobody else got it a
>> second time then it must be a problem my end, so please let me know!!!
>>
>
> I rec'd some 30 old messages today. Remember when Stephen Spector apologized
> for the mailing list being turned off because the hoster hadn't been paid?
> Before that, I used to get old/duplicate emails every Monday. (Some I did
> remember, some I didn't.) This is the first time since the apology that this
> has happened, at least noticeably so.
>
> _______________________________________________
> Xen-users mailing list
> Xen-***@lists.xensource.com
> http://lists.xensource.com/xen-users
>
Evan Miller
2008-06-23 23:57:25 UTC
Permalink
Hi everyone!

Where does Xen save the "DomU state saves"?

I have been trying to figure out the most time-proof partition scheme
for my set up and I was wondering if I could make the folder(?) where
Xen 3.2.1 save it's DomU states saves (what is the right expression for
this?) and put it on its own LVM partition here is why:


I only have 2GB RAM on my ML570. I will be upgrading memory as I need
(up to 32GB).

If Xen saves its DomU-saves to the Dom0's partition then as my server
receives more RAM and I will allocate more memory to DomUs that folder
with in Dom0 will expand to such large proportions that it chokes of
Dom0's hard drive space and crash the system. If I have a LVM in an
automatic mode resizing the partitions as needed I should always be in
good shape when it comes to that.

Of course this could all be avoided if Xen saves the states to the DomU
partition and reads them from there accordingly. Somehow I suspect that
Xen saves the DomU state saves somewhere on the Dom0 partition by
default (if you only have a "/" partition containing the whole Dom0).


I'm still attempting to figure out the best partitioning scheme for my
boxes...any help would be appreciated.

Thank you in advance,



Sincerely,



Evan Miller



+++++++++++++++++++++++++++

Hello Friends,

After over 30 hours of scouring the web for a recent comprehensive guide of
installing Xen on Debian Etch I feel like I have no choice but to post here
(my first mailing list post!).

I found many good guides, but it seems that they all lack:
A. recommended partitioning scheme
and/or
B. LVM set up




**************************************
I was following the http://www.howtoforge.com/debian_etch_xen_3.1 guide and
everything went well for a while, but the [new] Xen version was incompatible
with some of the instructions so I set out to look for a more recent guide
and found out that there is a much easier way to install Xen (from sources)
now and that I should use LVM.

The above link was the only one that gave the detailed partitioning
recommendations I needed:


• /boot 150 MB (Primary) (Location for the new partition: Beginning) (ext3)
(Bootable flag: on <-- important, otherwise your system will not boot!)
• swap 1GB (Logical) (Location for the new partition: Beginning)
• / 3GB (Logical) (Location for the new partition: Beginning) (ext3)
• /vserver the rest (Logical) (Location for the new partition: Beginning)
(ext3)

Unfortunately it is missing instructions for using LVM.


This guide mentions LVM, but has proprietary partitioning scheme and old Xen
version: http://www.d7031.de/text/xen_with_lvm_under_etch.shtml


http://www.cosmocode.de/en/blogs/gohr/20070130123639/ - This guide gets very
close covering both, but it is outdated and I am wary about mixing the
original guide's ( http://www.howtoforge.com/debian_etch_xen_3.1 )
partitioning scheme and this one.


I also was hoping to achieve the internal routing and the best guides that
seem to cover that are the original guide I mentioned and the
http://xgu.ru/wiki/Xenomips/en (later one is a bit beyond me at this time).




**************************************

I am sorry for the convoluted first post - I think it reflects my mind state
at this time! XD

I would like to introduce myself to all of you: My name is Evan, I am a *NIX
newbie, I have been "messing about" with Linux distos since 2001 and about
as long with FreeBSD. Unfortunately I have not ventured far beyond GUI and
always came back to Windows XP.

Lately I was put in charge of creating a test set up for our startup so I
have been forced to learn many things at once while producing some sort of
positive results on a very tight schedule.

We have decided that a Xen setup running on top of Etch was the way to go,
but actually implementing such a setup has proven to be very challenging.

I would appreciate any help, but please keep in mind my limited linux and
non-gui experience (I'm just learning to appreciate vi).




**************************************

Hardware:

I have 2 Xen candidates:

1. ML570 2G Server with 4 2.4GHz Xeons, 2GB PC 2100 Ram (6GB more coming)
and 6 15k 73GB SCSI drives (and 6 more to come) running on the the LSI 320-2
controller in Raid0 soon to be backed up on to 2 SATA 2 1TB Drives running
off a SATA 300 Promise controller.

2. Intel Pentium D 820 (dual core 2.8GHz) based desktop with 1GB ram and
on-board sata 150 running a 240GB SATA drive (more drives and memory will be
added). The P5LP-LE motherboard (
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00864946&lc=en&cc=us )
supports VT chips so at some point we may upgrade this box to Intel VT cpu
(I am not sure if I will have to reinstall the VT enabled Xen at that point
or not).


Eventually I would like to run a mix of:
http://lxer.com/module/forums/t/24435/ and http://xgu.ru/wiki/Xenomips/en
and have the ability to move live machines from the ML570 to the Desktop 820
D system at night to save on power.


**************************************

For now I would be happy with a solid partition recommendation to get me
started on the way to these goals.

I will start with the Desktop D 820 system with Etch running as Dom0 on a
250GB SATA drive.

I would like to eventually have a GUI access to managing Xen DomUs so I
thought I would mention this encase a 3GB root partition (
http://www.howtoforge.com/debian_etch_xen_3.1 ) would be too small.

Keeping all above in mind what would be the recommended partition scheme for
the 250GB drive?

**************************************




Thank you in advance,

Sincerely,

=)

Evan Miller

+++++++++++++++++++++++++++
Jeroen Torrekens
2008-06-24 09:05:07 UTC
Permalink
> -----Original Message-----
> From: xen-users-***@lists.xensource.com [mailto:xen-users-
> ***@lists.xensource.com] On Behalf Of Evan Miller
> Sent: dinsdag 24 juni 2008 1:57
> To: xen-***@lists.xensource.com
> Subject: [Xen-users] Where does Xen store its DomU-state saves?
> Partitioningand LVM Question
>
> Hi everyone!
>
> Where does Xen save the "DomU state saves"?
>
> I have been trying to figure out the most time-proof partition scheme
> for my set up and I was wondering if I could make the folder(?) where
> Xen 3.2.1 save it's DomU states saves (what is the right expression for
> this?) and put it on its own LVM partition here is why:
>
>
> I only have 2GB RAM on my ML570. I will be upgrading memory as I need
> (up to 32GB).
>
> If Xen saves its DomU-saves to the Dom0's partition then as my server
> receives more RAM and I will allocate more memory to DomUs that folder
> with in Dom0 will expand to such large proportions that it chokes of
> Dom0's hard drive space and crash the system. If I have a LVM in an
> automatic mode resizing the partitions as needed I should always be in
> good shape when it comes to that.
>
> Of course this could all be avoided if Xen saves the states to the DomU
> partition and reads them from there accordingly. Somehow I suspect that
> Xen saves the DomU state saves somewhere on the Dom0 partition by
> default (if you only have a "/" partition containing the whole Dom0).
>
>
> I'm still attempting to figure out the best partitioning scheme for my
> boxes...any help would be appreciated.
>
> Thank you in advance,
>
>
>
> Sincerely,
>
>
>
> Evan Miller

Hi,

As far as I recall, it should be in /var/lib/xen/save

Jeroen
Ferenc Wagner
2008-06-24 10:00:32 UTC
Permalink
"Jeroen Torrekens" <***@aserver.com> writes:

>> Where does Xen save the "DomU state saves"?
>
> As far as I recall, it should be in /var/lib/xen/save

By default, yes. You can configure it in /etc/default/xendomains.
--
Cheers,
Feri.
jim burns
2008-06-02 02:36:07 UTC
Permalink
On Sunday June 01 2008 09:22:44 am James Harper wrote:
> 've just made my first ever attempt at an Nullsoft installer, so if you
> want to try it download "Xen PV Drivers 0.9.5.exe" from
> http://www.meadowcourt.org/downloads/

I heartily recommend following the uninstall directions on:

http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing

Uninstalling

If you are upgrading from a pre-0.9.0 release, you will need to completely
purge the old drivers from your system.

*

Open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
*

Search for all occurences of UpperFilter or LowerFilter keys containing
xenhide.sys and delete them
* Delete Services\Xen* (anything in Services starting with Xen)
* Reboot, making sure not to select a boot entry that specifies /GPLPV

I was particularly surprised that there were still lots of Upper/LowerFilters
specifying xenhde that remove_xenhide_0.8.x.reg didn't catch. And I was
surprised that the Services\Xen* entries still made reference to the Wdf
versions, including one entry that was still at 1.5 instaed of 1.7. I then
went further and tried to delete:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Xen

but it wouldn't let me, even tho' a subkey of vbd referenced an UpperFilter
for xenaddresource. I then went into Add & Remove Programs and tried to
delete all the 'Windows Driver Package - Xen GPL PV Driver Developers (Xen*)
System (02/21/2008 0.8.0.0)' entries successfully. This removed all Xen PV
devices from Device Manager. It also removed all System Board devices for
some reason - but I haven't rebooted yet.

I then ran the .exe installer. While installing, I clicked on 'Details' and
saw, after the extraction phase:

Updating the driver...
Driver update has failed. (XP:0,-536870655)
Installing the driver...
Updating the driver...
The device is not plugged in, cannot update the driver.
Installing the driver...
[click on the first not signed warning]
Updating the driver...
The device is not plugged in, cannot update the driver.
Installing the driver...
[click on the second not signed warning]
[repeat above 4 lines for the third not signed warning]
[repeat the above 3 non bracketed lines 2 times]
Completed

Still no Xen PV devices in Device Manager, so I rebooted w/o /gplpv, which was
almost immediate, w/o the usual Shutting Down screen. Still no Xen PV
devices, or System Board devices. (Yeah, I'm being careful :-) Then I
rebooted w/ /gplpv. Qemu & Realtek still in control, no Xen PV or System
Board devices, even when you tick 'Show Hidden Devices'. Then ran the .exe
installer again. Same 'Detail' output as before, w/o any 'not signed' boxes
to click on. Rebooted w/ /gplpv again. No change. (Btw, there are no xen
anything programs in Add/Remove Programs, either. Nor were any of the
xen*.sys files in c:\windows\system32\drivers updated.)

I then tried installing 0.9.4. (Previous version installed was 0.9.2.) Install
was uneventful, and last screen said XenPCI Install failed, and all others
said 'Ready to use', The xen*.sys files in c:\windows\system32\drivers are
still from 0.9.2, and no appropriate devices in Device Manager. I then ran
Add Hardware Wizard, and told it to search automatically for new hardware and
got nothing.

I then shutdown, and started up again w/ /gplpv. No change.

Now I have to decide whether I want to do a virgin install of another winxp
domu.
James Harper
2008-06-02 03:16:50 UTC
Permalink
>
> I then tried installing 0.9.4. (Previous version installed was 0.9.2.)
> Install
> was uneventful, and last screen said XenPCI Install failed, and all
others
> said 'Ready to use', The xen*.sys files in c:\windows\system32\drivers
are
> still from 0.9.2, and no appropriate devices in Device Manager. I then
ran
> Add Hardware Wizard, and told it to search automatically for new
hardware
> and got nothing.

Can you please try the following:

. Remove all traces of xenpci from your system (delete
c:\windows\inf\oem*, delete c:\windows\system32\drivers\xen*.sys, and
maybe remove the services registry keys for luck too)
. Download 'debug view' from www.sysinternals.com, and run it. Make sure
that 'capture kernel' is enabled.
. Try installing the xenpci driver using 'update driver' from device
manager. The drivers will be in 'C:\Program Files\Xen PV
Drivers\drivers' if you ran the 0.9.5 installer.

I don't expect the above to work, given that you appear to have tried
everything I've suggested anyway, but when you install the driver,
'debug view' should capture some useful info and might tell me why it is
failing, so send the output to me and I'll have a look.

What is your impression, is this a problem with xenpci failing for some
reason, or a problem with your system due to previous installations of
the gpl pv drivers?

Thanks

James
jim burns
2008-06-02 08:47:00 UTC
Permalink
On Sunday June 01 2008 11:16:50 pm James Harper wrote:
> What is your impression, is this a problem with xenpci failing for some
> reason, or a problem with your system due to previous installations of
> the gpl pv drivers?

Probably the latter, since the installer is not finding any device to install
a driver to. I'll try 'debug view' when I get some time.

> and maybe remove the services registry keys for luck too)

Any keys you want me to remove not mentioned in your wiki? How about the
xenshutdownmon key?

Thanx.
jim burns
2008-06-04 02:13:00 UTC
Permalink
On Sunday June 01 2008 11:16:50 pm James Harper wrote:
> Can you please try the following:
>
> . Remove all traces of xenpci from your system (delete
> c:\windows\inf\oem*, delete c:\windows\system32\drivers\xen*.sys, and
> maybe remove the services registry keys for luck too)

Mostly done. I still can't delete HKLM\SYSTEM\CurrentControlSet\Enum\Xen, and
the only thing in [...]\Services\Xen* is XenShutdownMon, which I left. (There
is an Enum\PCI subkey that refers to the Xen PCI Device Driver. Should I do
something with it? There is also an Enum\ACPI subkey that refers to the PCI
Bus.) The Upper/LowerFilters were previously deleted, except for the one
referencing xenaddresource in Enum\Xen. There's nothing in Add/Remove
Programs, including anything that looks related to my previous 0.9.5
execution.

In the System Information tool (part of the Help Center), there are no *xen*
entries loaded in Software Environment -> System Drivers. I then did a search
from the top of the category view on 'xen': There are some resource
reservations for xenpci in Hardware Resources -> I/O & IRQs & Memory. (I
assume these reservations are setup from the Registry.) It does see the
xennet adapter in Components -> Network -> Adapter, tho' it says 'PNP Device
ID' is 'Not Available'. In Components -> Storage -> Problem Devices, it says
the Xen PCI Device Driver has the error code 'Failure using the VxD loader'.
Software Environment -> Services lists XenShutdownMon as Stopped. (Any
attempt to start it results in a failure notice in Event Viewer.)

Since you asked to delete the xen*.sys files, I rebooted w/ /gplpv, tho' there
still are not any System Board devices in Device Manager, including PCI Bus,
and Qemu and Realtek are still in charge. I then reran the search in the
System Information tool: no change from above.

> . Download 'debug view' from www.sysinternals.com, and run it. Make sure
> that 'capture kernel' is enabled.
> . Try installing the xenpci driver using 'update driver' from device
> manager. The drivers will be in 'C:\Program Files\Xen PV
> Drivers\drivers' if you ran the 0.9.5 installer.

Ran dbgview w/ all default options plus 'capture kernel', and ran the 0.9.6
installer. Got the same extracting, etc., messages from 'Details' as for
0.9.5, including the one about 'The device is not plugged in, cannot update
the driver.' Nothing in dbgview. The c:\Program Files\Xen PV
Drivers\drivers\*.inf files have the proper DriverVer string for 0.9.6.

The tried the 0.9.4 install.bat: 'Install Failed' for xenpci, and nothing in
dbgview. I assume this means the drivers were never even loaded.

I assume no debug output means I'm reinstalling winxp this weekend :-(
Geoff Wiener
2008-06-05 10:51:20 UTC
Permalink
James / Jim;

Thank you both for your feedback; both great ideas that I hadn't thought
of!

>James: If you partition that disk image, then reboot the DomU, is the
disk image still partitioned when you reboot? What I'm getting it is are
writes going through?

The short answer is "Yes" the partition persists, here is how I tested.

Template DomU (aka: xanb)
W2K3 R2 SP2
.NET Framework 2.0
PV 0.9.6 drivers (installed fresh, not upgraded)

Disk 0 5GB RAW, not sparse, formatted NTFS (from inside this VM)
DISK 1 2GB RAW, not sparse, never formatted

I used different size disks just to be sure I knew what I was looking at
everywhere.

Xanb.hvm

disk = [ 'file:/xenimages/xanb/xanb.img,hda,w',
'file:/xenimages/xanb/xanb-1.img,hdb,w' ]

Boot the DomU
Disk Management:
Disk 0, basic, 4.87 GB NTFS, Healthy (and it works)
Disk 1, basic, 2.00 Unallocated

Right click the partition on disk1, New Partition, Next, Primary
Partition, Next
Partition Size in MB: 2043 (default), Next
Assign the following drive letter: D: (default), Next
Format this partition with the following settings:
File System: NTFS
Allocation unit size: Default
Volume Label: New Volume, Next
Completing the New Partition Wizard, Finish

The format command counts, quickly up to 100% then states: The format
did not complete successfully (OK), Click OK
The partition is listed as "Healthy"
Windows Explorer
Drive "D" show in the tree, but cannot be used, "the disk in drive D is
not formatted, do you want to format it now?", "no"

Start, Run, CMD
Diskpart

List disk
DISK## Status Size Free
Disk 0 Online 4997 MB 8033 KB
DISK 1 Online 2044 MB 0 B

Shutdown Domu

Login, Disk Management
The partition is, as it was before, 2.00GB, Healthy
Windows Explorer, click on D:\ "Do you want to format it now?"
Diskpart, same as above

> Jim: try creating an image, and using mkfs.ntfs/mkntfs before
mounting. (Like all mkfs operations, use losetup on the image file to
get a loop device to pass to mkntfs, then losetup -d it.) Good luck.

I don't have any experience creating NTFS partitions in Linux so I am
using the same configuration as above except disk 1 is a copy of an NTFS
primary disk from a different windows DomU (that is currently shutdown).
The second image is, as before, a RAW file that is not sparse which has
been formatted inside the other DomU as NTFS.

Xanb.hvm
disk = [ 'file:/xenimages/xanb/xanb.img,hda,w',
'file:/xenimages/xanb/w2k3.img,hdb,w' ]

Disk 0 5GB RAW, not sparse, formatted NTFS (from inside this VM)
DISK 1 8GB RAW, not sparse, Formatted NTFS (from inside W2K3 VM)

Boot the DomU
Disk Management:
Disk 0, basic, 4.87 GB NTFS, Healthy (and it works)
Disk 1, basic, 7.99 GB NTFS, Healthy (Active)

Windows Explorer, Select D:\ (And it works!!!)

Opened files, created folders, moved files around

Attempted to format the already partitioned disk and that failed.
Rebooted without the /gplpvl switch and formatted the disk, that worked.
(Format Complete). I just noticed that when that format completed a
folder was created on the root of D:\ "System Volume Information". (I
suppose I never noticed that before because I never had trouble
formatting a disk).

Rebooted with the /gplpv switch and was able to use the new volume
without any trouble.

Diskpart
List disk
DISK## Status Size Free
Disk 0 Online 4997 MB 8033 KB
DISK 1 Online 8189 MB 8033 KB

Diskpart reports strange numbers for free space but I think that's not
uncommon.

I presume that means something is preventing us from writing to the
partition table properly from inside windows.

This problem is specific to formatting the disk from inside windows
reading / writing to existing, formatted partitions in Windows.

So now that we know what it is where do we start to troubleshoot this?
Do we look at Xen or the GPLPV windows driver source code? As I have not
written much code in many years I do not have a handle on how the
drivers talk to Xen in the first place. I would be interested in
learning though. Is there a primer on this anywhere? Is this
specifically related to the Xen frontend and backend drivers and the use
of the xenstore for passing info back and forth? Any links or
documentation you can provide, James, would be great. I would like to
understand this in more depth.

Oh lastly - All this got me thinking about the issue I was having with
tap:qcow and qcow image files. If there is an issue creating partitions
and formatting disks I wondered what would happen if I converted an
existing RAW file that works with the GPLPV drivers (the one I used for
testing above) to a qcow image.

qemu-img convert xanb.img -O qcow xanb.qcow

disk = [ 'tap:qcow:/xenimages/xanb/xanb.qcow,hda,w' ]

Unfortunately this didn't resolve that issue. Using tap:aio: with raw
files actually works, but not tap:qcow with qcow files (BSODs as
before).

Thanks for your suggestions guys - this has definitely progressed things
for me and hopefully others will benefit from our discussion.

Best Regards

Geoff


-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 05 June 2008 12:20 AM
To: Geoff Wiener; jim burns; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> Hi Jim;
>
> Yes definitely - I have tried both hot plugging as well as adding to
the
> disk line. In every case I specify that the disk should be writable.
> It lets me create the partition which should be a write operation, but
> then shows the disk as having 0K free space.
>

If you partition that disk image, then reboot the DomU, is the disk
image still partitioned when you reboot? What I'm getting it is are
writes going through?

James
jim burns
2008-06-05 21:09:02 UTC
Permalink
On Thursday June 05 2008 06:51:20 am Geoff Wiener wrote:
> Thank you both for your feedback; both great ideas that I hadn't thought
> of!
>
>>James:  If you partition that disk image, then reboot the DomU, is the
>
>> disk image still partitioned when you reboot? What I'm getting it is are
>> writes going through?
>
> The short answer is "Yes" the partition persists, here is how I tested.

Ok, so basically, your tests show that formatting within the hvm works when
booted w/o /gplpv, and does not when booted w/ /gplpv. It sounds like
something is not being finalized by the gplpv drivers.

> Right click the partition on disk1, New Partition, Next, Primary
> Partition, Next
> Partition Size in MB: 2043 (default), Next
> Assign the following drive letter: D: (default), Next
> Format this partition with the following settings:
> File System: NTFS
> Allocation unit size: Default
> Volume Label: New Volume, Next
> Completing the New Partition Wizard, Finish

> The format command counts, quickly up to 100% then states: The format
> did not complete successfully (OK), Click OK

I'm not familiar with Windows Server 'Disk Management', but it sounds like
fdisk and format from a Windows desktop os all rolled into one. Is there an
option to choose between 'quick' format, and 'thorough' format?

> Attempted to format the already partitioned disk and that failed.
> Rebooted without the /gplpvl switch and formatted the disk, that worked.
[...]
> This problem is specific to formatting the disk from inside windows
> reading / writing to existing, formatted partitions in Windows.

> So now that we know what it is where do we start to troubleshoot this?
> Do we look at Xen or the GPLPV windows driver source code? As I have not

My impression is if formatting works on qemu, and not on xen pv, that we are
hitting an untested case in gplpv.

James - have you tried formatting a xen pv disk? (I hope this is not another
one of those 'works for some distros and not others' problem. I've noticed
that there have been no complaints about qemu and xen pv both being loaded
since the rewrite in the 0.9.0 series.)
Ruslan Sivak
2008-06-05 22:01:19 UTC
Permalink
>> So now that we know what it is where do we start to troubleshoot this?
>> Do we look at Xen or the GPLPV windows driver source code? As I have not
>>
>
> My impression is if formatting works on qemu, and not on xen pv, that we are
> hitting an untested case in gplpv.
>
> James - have you tried formatting a xen pv disk? (I hope this is not another
> one of those 'works for some distros and not others' problem. I've noticed
> that there have been no complaints about qemu and xen pv both being loaded
> since the rewrite in the 0.9.0 series.)
>
> _______________________________________________
> Xen-users mailing list
> Xen-***@lists.xensource.com
> http://lists.xensource.com/xen-users
>

Actually I have that complaint. After you install, on first boot, the
new devices are not installed properly under win2008. After manually
updating the drivers, both are loaded and after a reboot the system is
usually hosed.

Russ
jim burns
2008-06-05 22:18:03 UTC
Permalink
On Thursday June 05 2008 06:01:19 pm Ruslan Sivak wrote:
> > James - have you tried formatting a xen pv disk? (I hope this is not
> > another one of those 'works for some distros and not others' problem.
> > I've noticed that there have been no complaints about qemu and xen pv
> > both being loaded since the rewrite in the 0.9.0 series.)
> >

> Actually I have that complaint.  After you install, on first boot, the
> new devices are not installed properly under win2008.  After manually
> updating the drivers, both are loaded and after a reboot the system is
> usually hosed.

Yeh, I noticed your post right after I sent mine :-)
Ruslan Sivak
2008-06-05 22:24:19 UTC
Permalink
Ruslan Sivak wrote:
>
>>> So now that we know what it is where do we start to troubleshoot this?
>>> Do we look at Xen or the GPLPV windows driver source code? As I have
>>> not
>>>
>>
>> My impression is if formatting works on qemu, and not on xen pv, that
>> we are hitting an untested case in gplpv.
>>
>> James - have you tried formatting a xen pv disk? (I hope this is not
>> another one of those 'works for some distros and not others' problem.
>> I've noticed that there have been no complaints about qemu and xen pv
>> both being loaded since the rewrite in the 0.9.0 series.)
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-***@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>
> Actually I have that complaint. After you install, on first boot, the
> new devices are not installed properly under win2008. After manually
> updating the drivers, both are loaded and after a reboot the system is
> usually hosed.
> Russ
>
So I keep reinstalling and hosing my system. Is there a proper order to
install this? How do I go about making an LVM snapshot and restoring to
it after the system gets hosed?

Russ
jim burns
2008-06-05 22:51:36 UTC
Permalink
On Thursday June 05 2008 06:24:19 pm Ruslan Sivak wrote:
> So I keep reinstalling and hosing my system.  Is there a proper order to
> install this?

I didn't ask before, but I'm assuming you are using 0.9.5 or up, with the gui
installer, so there is no real choice about order. Previous versions used a
dos .bat file, and there were manual install procedures before that.
Basically, xenpci.inf/.sys gets installed first, which creates other devices
the other drivers attach to, while xenhide.sys is *supposed* to hide the
qemu/realtek devices. And the install probably should be done with out any
xen pv drivers loaded, such as when you boot w/o /gplpv.

If it doesn't work for you, report it (as you have), and James will probably
ask you for more info. Don't keep hosing your system - either it works or it
doesn't. :-(

On snapshots, search the list. This has been discussed a lot in the last two
months.
r***@vshift.com
2008-06-05 23:21:23 UTC
Permalink
Sorry for the top post, I'm on a blackberry.

I am using the latest - 0.9.6 I believe.
Here is what I did in the latest one:
Did. a clean install of win2k8 standard x32.
Enabled testsigning using bcdedit, but did not reboot.
Downloaded and installed the latest from James. I got prompts about unsigned drivers, but I said to install anyway.
Followed the wiki to create a new bootentry.
Set that entry as default.
Rebooted.
Upon reboot, the old devices were showing up, and the new pci device had a problem. Upon manually installing the driver for it, it detects the other devices, but doesn't disable the old ones.
Upon reboot it will not proceed past the boot menu claiming the exe is corrupted.

Hope this helps. I will try rebooting after enabling test signing and see if that helps.

Russ
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: jim burns <***@bellsouth.net>

Date: Thu, 5 Jun 2008 18:51:36
To:xen-***@lists.xensource.com
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows


On Thursday June 05 2008 06:24:19 pm Ruslan Sivak wrote:
> So I keep reinstalling and hosing my system.  Is there a proper order to
> install this?

I didn't ask before, but I'm assuming you are using 0.9.5 or up, with the gui
installer, so there is no real choice about order. Previous versions used a
dos .bat file, and there were manual install procedures before that.
Basically, xenpci.inf/.sys gets installed first, which creates other devices
the other drivers attach to, while xenhide.sys is *supposed* to hide the
qemu/realtek devices. And the install probably should be done with out any
xen pv drivers loaded, such as when you boot w/o /gplpv.

If it doesn't work for you, report it (as you have), and James will probably
ask you for more info. Don't keep hosing your system - either it works or it
doesn't. :-(

On snapshots, search the list. This has been discussed a lot in the last two
months.

_______________________________________________
Xen-users mailing list
Xen-***@lists.xensource.com
http://lists.xensource.com/xen-users
James Harper
2008-06-06 01:57:44 UTC
Permalink
> Sorry for the top post, I'm on a blackberry.

I have the same problem on my Windows Mobile PDA...

> I am using the latest - 0.9.6 I believe.
> Here is what I did in the latest one:
> Did. a clean install of win2k8 standard x32.
> Enabled testsigning using bcdedit, but did not reboot.
> Downloaded and installed the latest from James. I got prompts about
> unsigned drivers, but I said to install anyway.
> Followed the wiki to create a new bootentry.
> Set that entry as default.
> Rebooted.
> Upon reboot, the old devices were showing up, and the new pci device
had a
> problem. Upon manually installing the driver for it, it detects the
other
> devices, but doesn't disable the old ones.
> Upon reboot it will not proceed past the boot menu claiming the exe is
> corrupted.

Ah. Yes, don't install drivers when you are booting with GPLPV! Is this
what you did? The class filter (xenhide.sys) will fail to disable the
qemu devices but won't disable the xen devices either.

I'll try and spell that out a bit more clearly on the wiki. I can't
think of a way around it at this point...

James
Ruslan Sivak
2008-06-06 04:50:33 UTC
Permalink
James Harper wrote:
>> Sorry for the top post, I'm on a blackberry.
>>
>
> I have the same problem on my Windows Mobile PDA...
>
>
>> I am using the latest - 0.9.6 I believe.
>> Here is what I did in the latest one:
>> Did. a clean install of win2k8 standard x32.
>> Enabled testsigning using bcdedit, but did not reboot.
>> Downloaded and installed the latest from James. I got prompts about
>> unsigned drivers, but I said to install anyway.
>> Followed the wiki to create a new bootentry.
>> Set that entry as default.
>> Rebooted.
>> Upon reboot, the old devices were showing up, and the new pci device
>>
> had a
>
>> problem. Upon manually installing the driver for it, it detects the
>>
> other
>
>> devices, but doesn't disable the old ones.
>> Upon reboot it will not proceed past the boot menu claiming the exe is
>> corrupted.
>>
>
> Ah. Yes, don't install drivers when you are booting with GPLPV! Is this
> what you did? The class filter (xenhide.sys) will fail to disable the
> qemu devices but won't disable the xen devices either.
>
> I'll try and spell that out a bit more clearly on the wiki. I can't
> think of a way around it at this point...
>
> James
>
Well the only reason I did that is because it didn't install/activate
properly the first time. Did I do some steps wrong? This was a fresh
install of Windows, so I didn't have any previous derivers installed.

Russ
Ruslan Sivak
2008-06-06 21:52:46 UTC
Permalink
Ruslan Sivak wrote:
> James Harper wrote:
>>> Sorry for the top post, I'm on a blackberry.
>>>
>>
>> I have the same problem on my Windows Mobile PDA...
>>
>>
>>> I am using the latest - 0.9.6 I believe.
>>> Here is what I did in the latest one:
>>> Did. a clean install of win2k8 standard x32.
>>> Enabled testsigning using bcdedit, but did not reboot.
>>> Downloaded and installed the latest from James. I got prompts about
>>> unsigned drivers, but I said to install anyway.
>>> Followed the wiki to create a new bootentry.
>>> Set that entry as default.
>>> Rebooted.
>>> Upon reboot, the old devices were showing up, and the new pci device
>>>
>> had a
>>
>>> problem. Upon manually installing the driver for it, it detects the
>>>
>> other
>>
>>> devices, but doesn't disable the old ones.
>>> Upon reboot it will not proceed past the boot menu claiming the exe is
>>> corrupted.
>>>
>>
>> Ah. Yes, don't install drivers when you are booting with GPLPV! Is this
>> what you did? The class filter (xenhide.sys) will fail to disable the
>> qemu devices but won't disable the xen devices either.
>>
>> I'll try and spell that out a bit more clearly on the wiki. I can't
>> think of a way around it at this point...
>>
>> James
>>
> Well the only reason I did that is because it didn't install/activate
> properly the first time. Did I do some steps wrong? This was a fresh
> install of Windows, so I didn't have any previous derivers installed.
> Russ
>


I finally got it to work. The drivers were not being installed even on
with testsigning on (didn't seem to make a difference). I installed the
drivers, got a warning but told it to ignore it, but the drivers were
still not showing up as installed in device manager. I think installed
them manually through the device manager before rebooting and then set
up the boot entries. This made it work, but the performance seems
pretty bad. Originally I was averaging around 70mb/s on a system that
does about 340 MB/s as measured by hdparm -t. After installing the
drivers, I'm not averaging 18MB/s. Did I do something wrong? I though
these drivers were supposed to give better performance, not worse?

This is my disk line if it helps:

disk = [ 'phy:/dev/mapper/VolGroup00-lvol2,hda,w',
'file:/mnt/isos/en_windows_server_2008_datacenter_enterprise_standard_x86_dvd_X14-26710.iso,ioemu:hdc:cdrom,r']


Russ
Ruslan Sivak
2008-06-06 23:46:54 UTC
Permalink
>
> I finally got it to work. The drivers were not being installed even
> on with testsigning on (didn't seem to make a difference). I
> installed the drivers, got a warning but told it to ignore it, but the
> drivers were still not showing up as installed in device manager. I
> think installed them manually through the device manager before
> rebooting and then set up the boot entries. This made it work, but
> the performance seems pretty bad. Originally I was averaging around
> 70mb/s on a system that does about 340 MB/s as measured by hdparm -t.
> After installing the drivers, I'm not averaging 18MB/s. Did I do
> something wrong? I though these drivers were supposed to give better
> performance, not worse?
> This is my disk line if it helps:
>
> disk = [ 'phy:/dev/mapper/VolGroup00-lvol2,hda,w',
> 'file:/mnt/isos/en_windows_server_2008_datacenter_enterprise_standard_x86_dvd_X14-26710.iso,ioemu:hdc:cdrom,r']
>
>
>

I just installed the drivers on Win2k3 x64, and I'm seeing the same
slowdown.

Russ
Ruslan Sivak
2008-06-06 23:50:00 UTC
Permalink
Ruslan Sivak wrote:
>
>>
>> I finally got it to work. The drivers were not being installed even
>> on with testsigning on (didn't seem to make a difference). I
>> installed the drivers, got a warning but told it to ignore it, but
>> the drivers were still not showing up as installed in device
>> manager. I think installed them manually through the device manager
>> before rebooting and then set up the boot entries. This made it
>> work, but the performance seems pretty bad. Originally I was
>> averaging around 70mb/s on a system that does about 340 MB/s as
>> measured by hdparm -t. After installing the drivers, I'm not
>> averaging 18MB/s. Did I do something wrong? I though these drivers
>> were supposed to give better performance, not worse?
>> This is my disk line if it helps:
>>
>> disk = [ 'phy:/dev/mapper/VolGroup00-lvol2,hda,w',
>> 'file:/mnt/isos/en_windows_server_2008_datacenter_enterprise_standard_x86_dvd_X14-26710.iso,ioemu:hdc:cdrom,r']
>>
>>
>>
>
> I just installed the drivers on Win2k3 x64, and I'm seeing the same
> slowdown.
> Russ
>

Also the shutdown monitor won't work. I'm getting "The application
failed to initialize properly (0xc0000135). Click on OK to terminate the
application."

Russ
James Harper
2008-06-06 01:23:02 UTC
Permalink
> >>> So now that we know what it is where do we start to troubleshoot
this?
> >>> Do we look at Xen or the GPLPV windows driver source code? As I
have
> >>> not
> >>>
> >>
> >> My impression is if formatting works on qemu, and not on xen pv,
that
> >> we are hitting an untested case in gplpv.
> >>
> >> James - have you tried formatting a xen pv disk? (I hope this is
not
> >> another one of those 'works for some distros and not others'
problem.
> >> I've noticed that there have been no complaints about qemu and xen
pv
> >> both being loaded since the rewrite in the 0.9.0 series.)

You know, I thought I had. But I just tried it and it behaved exactly as
the OP describe it, so obviously I hadn't tried recently.

DebugView shows a whole lot of stuff happening, but nothing that leaps
out as being wrong. I'll investigate.

Thanks for reporting this.

James
James Harper
2008-06-07 01:36:07 UTC
Permalink
can you try running it froa command prompt?
Do you have .net framework 2.0 installed?

-----Original Message-----
From: "Ruslan Sivak"<***@vshift.com>
Sent: 7/06/08 9:50:15 AM
To: "James Harper"<***@bendigoit.com.au>
Cc: "xen-***@lists.xensource.com"<xen-***@lists.xensource.com>, "jim burns"<***@bellsouth.net>
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

Ruslan Sivak wrote:
>
>>
>> I finally got it to work. The drivers were not being installed even
>> on with testsigning on (didn't seem to make a difference). I
>> installed the drivers, got a warning but told it to ignore it, but
>> the drivers were still not showing up as installed in device
>> manager. I think installed them manually through the device manager
>> before rebooting and then set up the boot entries. This made it
>> work, but the performance seems pretty bad. Originally I was
>> averaging around 70mb/s on a system that does about 340 MB/s as
>> measured by hdparm -t. After installing the drivers, I'm not
>> averaging 18MB/s. Did I do something wrong? I though these drivers
>> were supposed to give better performance, not worse?
>> This is my disk line if it helps:
>>
>> disk = [ 'phy:/dev/mapper/VolGroup00-lvol2,hda,w',
>> 'file:/mnt/isos/en_windows_server_2008_datacenter_enterprise_standard_x86_dvd_X14-26710.iso,ioemu:hdc:cdrom,r']
>>
>>
>>
>
> I just installed the drivers on Win2k3 x64, and I'm seeing the same
> slowdown.
> Russ
>

Also the shutdown monitor won't work. I'm getting "The application
failed to initialize properly (0xc0000135). Click on OK to terminate the
application."

Russ
r***@vshift.com
2008-06-07 03:26:38 UTC
Permalink
That was probably it. 2K8 comes with .net preinstalled, but 2k3 doesn't.
What about the performance issues? Are those the kind of numbers I should be expecting? If they are, is there a way to install the shutdown monitor, but not install the disk drivers?

Russ
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "James Harper" <***@bendigoit.com.au>

Date: Sat, 7 Jun 2008 11:36:07
To:<***@vshift.com>, <***@bendigoit.com.au>
Cc:xen-***@lists.xensource.com, ***@bellsouth.net
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows


can you try running it froa command prompt?
Do you have .net framework 2.0 installed?

-----Original Message-----
From: "Ruslan Sivak"<***@vshift.com>
Sent: 7/06/08 9:50:15 AM
To: "James Harper"<***@bendigoit.com.au>
Cc: "xen-***@lists.xensource.com"<xen-***@lists.xensource.com>, "jim burns"<***@bellsouth.net>
Subject: Re: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

Ruslan Sivak wrote:
>
>>
>> I finally got it to work. The drivers were not being installed even
>> on with testsigning on (didn't seem to make a difference). I
>> installed the drivers, got a warning but told it to ignore it, but
>> the drivers were still not showing up as installed in device
>> manager. I think installed them manually through the device manager
>> before rebooting and then set up the boot entries. This made it
>> work, but the performance seems pretty bad. Originally I was
>> averaging around 70mb/s on a system that does about 340 MB/s as
>> measured by hdparm -t. After installing the drivers, I'm not
>> averaging 18MB/s. Did I do something wrong? I though these drivers
>> were supposed to give better performance, not worse?
>> This is my disk line if it helps:
>>
>> disk = [ 'phy:/dev/mapper/VolGroup00-lvol2,hda,w',
>> 'file:/mnt/isos/en_windows_server_2008_datacenter_enterprise_standard_x86_dvd_X14-26710.iso,ioemu:hdc:cdrom,r']
>>
>>
>>
>
> I just installed the drivers on Win2k3 x64, and I'm seeing the same
> slowdown.
> Russ
>

Also the shutdown monitor won't work. I'm getting "The application
failed to initialize properly (0xc0000135). Click on OK to terminate the
application."

Russ

_______________________________________________
Xen-users mailing list
Xen-***@lists.xensource.com
http://lists.xensource.com/xen-users
James Harper
2008-06-07 04:32:00 UTC
Permalink
> That was probably it. 2K8 comes with .net preinstalled, but 2k3
doesn't.
> What about the performance issues? Are those the kind of numbers I
should
> be expecting?

Well... obviously the PV drivers should be running much better than the
HVM devices. I'm trying to fix the 'format' problem that was described
recently at the moment. I'll re-visit the performance issues shortly. I
suspect that on some systems, windows hands out lots of unaligned
buffers which will slow things down drastically. I'll try and put some
monitoring to catch when this occurs excessively and log something in
the event log. At least then I'll be able to get some feedback on if
these event log messages appear when performance is bad.

Can you tell me what systems you've measured performance on? Are they
all 'bad'?

> If they are, is there a way to install the shutdown
> monitor, but not install the disk drivers?

Just don't boot with /GPLPV. xenpci will still activate and shutdown
will still work, but you won't get the PV block or network drivers,
which is what you want in this case.

James
Joost van den Broek
2008-06-07 11:23:47 UTC
Permalink
I'm sorry to react on a random posted message, I just subscribed this
mailinglist. I've currently installed the 0.9.6 drivers which are a
major step forward since the last time I tried your drivers (0.8.x). The
sustained transferrate of the scsi driver might not be as good as it
could be, but on the other hand I am very impressed by it's I/O speed
measured with IOMeter. It even outperformed the closed-source driver
found in XenServer 4.0.1! Well that test was run on possibly slower
disks, but same CPU, RAM and 4xRAID5 SATA.

Also "reallife" performance, as in just using the system, is at least to
call impressive. Very responsive, definitely enterprise ready. There is
just one thing I'm struggling with. Somehow the Tx network traffic (seen
from the HVM) is to DomU's and other nodes on the lan is very slow. On
the other hand it's just fine to Dom0 (about 1Gbit/s). Below are some
measurements done with iperf, all executed from the Windows HVM:

#iperf -c LinuxPV-DomU -l 1M -w 1M
------------------------------------------------------------
Client connecting to 192.168.1.25, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[1884] local 192.168.1.65 port 1495 connected with 192.168.1.25 port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-35.1 sec 2.00 MBytes 478 Kbits/sec

#iperf -c Dom0 -l 1M -w 1M
------------------------------------------------------------
Client connecting to 192.168.1.90, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[1884] local 192.168.1.65 port 1496 connected with 192.168.1.90 port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-10.0 sec 1.21 GBytes 1.04 Gbits/sec

#iperf -c OtherLanHost100mbit -l 1M -w 1M
------------------------------------------------------------
Client connecting to 192.168.1.3, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[1884] local 192.168.1.65 port 1497 connected with 192.168.1.3 port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-10.1 sec 46.0 MBytes 38.3 Mbits/sec

Running these tests from LinuxPV DomU <-> LinuxPV DomU gives about
500-700mbit. Somehow this only affects the HVM's outgoing traffic,
running iperf as a server on the Windows HVM and testing it from LinuxPV
DomU gives me this result:

test1:/tmp# iperf -c WindowsHVM -l 0.5M -w 0.5M
------------------------------------------------------------
Client connecting to 192.168.1.65, TCP port 5001
TCP window size: 1.00 MByte (WARNING: requested 512 KByte)
------------------------------------------------------------
[ 3] local 192.168.1.25 port 37641 connected with 192.168.1.65 port 5001
[ 3] 0.0-10.0 sec 599 MBytes 502 Mbits/sec

I tried enabling/disabling tx checksumming with ethtool on the HVM's vif
interface, changed the Xen Net Device Driver options, all with no luck.

These tests were performed on a AMD Opteron 1210 1.8ghz, HVM and DomU's
running 512MB RAM and Dom0 running on Debian Etch with Xen 3.2.0 from
backports. The tested Windows HVM is running Windows Server 2003 R2 SP2
EN 32-bit set to 1 vcpu with the latest GPL PV drivers (0.9.6)
installed. The onboard NIC is a Broadcom BCM5721, not the greatest, but
that shouldn't matter in this case. The Linux PV's are performing well,
so there has to be something wrong with the GPL PV drivers or settings.
Any suggestion?

Joost
James Harper
2008-06-07 11:37:37 UTC
Permalink
>
> I'm sorry to react on a random posted message, I just subscribed this
> mailinglist. I've currently installed the 0.9.6 drivers which are a
> major step forward since the last time I tried your drivers (0.8.x).
The
> sustained transferrate of the scsi driver might not be as good as it
> could be, but on the other hand I am very impressed by it's I/O speed
> measured with IOMeter. It even outperformed the closed-source driver
> found in XenServer 4.0.1! Well that test was run on possibly slower
> disks, but same CPU, RAM and 4xRAID5 SATA.

Hmmmm... now I'm baffled. I'm getting reports of really high performance
with the newer releases, and other reports of really poor performance.

> Also "reallife" performance, as in just using the system, is at least
to
> call impressive. Very responsive, definitely enterprise ready. There
is
> just one thing I'm struggling with. Somehow the Tx network traffic
(seen
> from the HVM) is to DomU's and other nodes on the lan is very slow. On
> the other hand it's just fine to Dom0 (about 1Gbit/s). Below are some
> measurements done with iperf, all executed from the Windows HVM:
>
> I tried enabling/disabling tx checksumming with ethtool on the HVM's
vif
> interface, changed the Xen Net Device Driver options, all with no
luck.

I've just been examining the code that controls that and it's not
working, so gso, sg, and csum offload are all 'stuck' in the on state,
regardless of what you set the device controls to. I'll investigate.

> These tests were performed on a AMD Opteron 1210 1.8ghz, HVM and
DomU's
> running 512MB RAM and Dom0 running on Debian Etch with Xen 3.2.0 from
> backports. The tested Windows HVM is running Windows Server 2003 R2
SP2
> EN 32-bit set to 1 vcpu with the latest GPL PV drivers (0.9.6)
> installed. The onboard NIC is a Broadcom BCM5721, not the greatest,
but
> that shouldn't matter in this case.

That sounds identical to my test environment. You wouldn't be running a
HP ML115 would you?

> The Linux PV's are performing well,
> so there has to be something wrong with the GPL PV drivers or
settings.
> Any suggestion?

Not that this point. All I've really tested with the network is DomU <->
Dom0 and, to a lesser extent, DomU <-> physical LAN.

I've just fixed a bug which was preventing formatting of a xenvbd device
under Windows and am just getting back to being able to use 'xm
block-detach' without getting a BSoD. If I can fix that quickly I'll do
a binary release tonight.

James
Joost van den Broek
2008-06-07 13:20:13 UTC
Permalink
James Harper schreef:
> That sounds identical to my test environment. You wouldn't be running a
> HP ML115 would you?
>
As a matter of fact, I do :-) I've replaced the shipped memory with
2x2GB Kingston memory and inserted 4x Barracuda ES 500GB drives
(ST3500630NS). I must say, this ML115 works pretty smooth with the Linux
DomU's and now also partly with Windows, thanks to you :-)

I also did another test with both HDTach and HD Tune (I know, not very
reliable, but just for comparison) and those programs normally give back
the same result. However, with GPLPV loaded, I get an average read of
43.2MB/s with HDtach and only 13.9MB/s with HD Tune. That's a big gap I
would say. Access time is in both cases acceptable (6.9ms in HD Tune).
But then again, I don't think these tests are very reliable and the
responsiveness of the system is IMHO much more important than it's max STR.

Joost
Geoff Wiener
2008-06-07 11:29:09 UTC
Permalink
Hi James;

I've been following this thread. On the "format" issue I noticed in
Device Manager that the Disk Properties, Location, on the General tab
reads Bus Number 0, Target ID 0, Lun0 for both disks. From my
experience with iSCSI the Location information in device manage is
obtained from the initiator and is accurate. Does your driver reflect
this information correctly? If so having two LUN0's on the same Target
ID would certainly confuse Windows.

Thanks for looking into this issue and feel free to tell me to leave you
alone :-). I am, of course, available to help you test at any time.

Best Regards

Geoff


-----Original Message-----
From: xen-users-***@lists.xensource.com
[mailto:xen-users-***@lists.xensource.com] On Behalf Of James Harper
Sent: 07 June 2008 5:32 AM
To: ***@vshift.com; xen-users-***@lists.xensource.com
Cc: xen-***@lists.xensource.com; ***@bellsouth.net
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> That was probably it. 2K8 comes with .net preinstalled, but 2k3
doesn't.
> What about the performance issues? Are those the kind of numbers I
should
> be expecting?

Well... obviously the PV drivers should be running much better than the
HVM devices. I'm trying to fix the 'format' problem that was described
recently at the moment. I'll re-visit the performance issues shortly. I
suspect that on some systems, windows hands out lots of unaligned
buffers which will slow things down drastically. I'll try and put some
monitoring to catch when this occurs excessively and log something in
the event log. At least then I'll be able to get some feedback on if
these event log messages appear when performance is bad.

Can you tell me what systems you've measured performance on? Are they
all 'bad'?

> If they are, is there a way to install the shutdown
> monitor, but not install the disk drivers?

Just don't boot with /GPLPV. xenpci will still activate and shutdown
will still work, but you won't get the PV block or network drivers,
which is what you want in this case.

James
James Harper
2008-06-07 11:41:45 UTC
Permalink
> Hi James;
>
> I've been following this thread. On the "format" issue I noticed in
> Device Manager that the Disk Properties, Location, on the General tab
> reads Bus Number 0, Target ID 0, Lun0 for both disks. From my
> experience with iSCSI the Location information in device manage is
> obtained from the initiator and is accurate. Does your driver reflect
> this information correctly? If so having two LUN0's on the same
Target
> ID would certainly confuse Windows.

They are on separate 'controllers', so there is no resulting confusing.

I have actually just fixed the formatting issue. It was related to
windows giving us buffers that were not aligned to a 512 byte boundary,
which the vbd backend driver won't accept. My workaround involves a huge
hit in performance and also had a nasty bug in it and that was causing
the format issue.

Not yet checked into hg so you'll have to wait a bit. If I don't get the
other bug resolved to be able to do a binary release, I'll at least
check in the format fix to hg.

James
Geoff Wiener
2008-06-07 11:59:09 UTC
Permalink
James;

That's brilliant news, thanks for sorting that. I wonder if this might
help with the tap:qcow issue too. I'll test both items as soon as you
release. Good work - you are fast!

G

-----Original Message-----
From: James Harper [mailto:***@bendigoit.com.au]
Sent: 07 June 2008 12:42 PM
To: Geoff Wiener; xen-***@lists.xensource.com
Subject: RE: [Xen-users] Release 0.9.5 of GPL PV Drivers for Windows

> Hi James;
>
> I've been following this thread. On the "format" issue I noticed in
> Device Manager that the Disk Properties, Location, on the General tab
> reads Bus Number 0, Target ID 0, Lun0 for both disks. From my
> experience with iSCSI the Location information in device manage is
> obtained from the initiator and is accurate. Does your driver reflect
> this information correctly? If so having two LUN0's on the same
Target
> ID would certainly confuse Windows.

They are on separate 'controllers', so there is no resulting confusing.

I have actually just fixed the formatting issue. It was related to
windows giving us buffers that were not aligned to a 512 byte boundary,
which the vbd backend driver won't accept. My workaround involves a huge
hit in performance and also had a nasty bug in it and that was causing
the format issue.

Not yet checked into hg so you'll have to wait a bit. If I don't get the
other bug resolved to be able to do a binary release, I'll at least
check in the format fix to hg.

James
Ruslan Sivak
2008-06-07 16:13:56 UTC
Permalink
James Harper wrote:
> Well... obviously the PV drivers should be running much better than the
> HVM devices. I'm trying to fix the 'format' problem that was described
> recently at the moment. I'll re-visit the performance issues shortly. I
> suspect that on some systems, windows hands out lots of unaligned
> buffers which will slow things down drastically. I'll try and put some
> monitoring to catch when this occurs excessively and log something in
> the event log. At least then I'll be able to get some feedback on if
> these event log messages appear when performance is bad.
>
> Can you tell me what systems you've measured performance on? Are they
> all 'bad'?
>
>
So far tested with Win2k3 and Win2k8. One 32 bit one 64 bit I believe.
I'll have to check again on monday, but so far it seems to be fairly
constant.
Andrej Javoršek
2008-06-07 10:47:10 UTC
Permalink
On 7.6.2008, at 6:32, James Harper wrote:

>> That was probably it. 2K8 comes with .net preinstalled, but 2k3
> doesn't.
>> What about the performance issues? Are those the kind of numbers I
> should
>> be expecting?
>
> Well... obviously the PV drivers should be running much better than
> the
> HVM devices. I'm trying to fix the 'format' problem that was described
> recently at the moment. I'll re-visit the performance issues
> shortly. I
> suspect that on some systems, windows hands out lots of unaligned
> buffers which will slow things down drastically. I'll try and put some
> monitoring to catch when this occurs excessively and log something in
> the event log. At least then I'll be able to get some feedback on if
> these event log messages appear when performance is bad.
>
> Can you tell me what systems you've measured performance on? Are they
> all 'bad'?
>
>> If they are, is there a way to install the shutdown
>> monitor, but not install the disk drivers?
>
> Just don't boot with /GPLPV. xenpci will still activate and shutdown
> will still work, but you won't get the PV block or network drivers,
> which is what you want in this case.
>
> James

Reading this mail I found out that the main cause of problems on my
OpenSolaris instalation
is probably in xenpci, because after installing PV drivers that
disables boot of Windows with
or without /gplpv option.
With /gplpv option I get BSOD (boot device inaccessible), after Widows
logo (with dummy progress indicator)
without /gplpv Windows just freezes on Windows logo (progress
indicator stops running).

Andrej

BTW: It seems I'm unable to post to the list, but can't find reason why!
>
Continue reading on narkive:
Loading...