I wonder if dscow (http://wiki.xensource.com/xenwiki/DmUserspace) works on Windows guest. If anyone gets it working, please let me know. Currently, I''ve got an error Error: Device 768 (vbd) could not be connected. Hotplug scripts not working. (XEN) (GUEST: 4) unsupported PCI BIOS function 0x0E (XEN) (GUEST: 4) int13_harddisk: function 15, unmapped device for ELDL=81 (XEN) HVM_PIT: guest freq in cycles=18647687 qemu: could not open hard disk image ''dscow:/tmp/windowsbase.dscow:/xenimages/windowsbase.img'' Thank you. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> I wonder if dscow (http://wiki.xensource.com/xenwiki/DmUserspace) OS> works on Windows guest. If anyone gets it working, please let me OS> know. Currently, I''ve got an error Currently, the Xen tools do not do the same amount of setup for HVM domains, which means that more complex disk types (blktap, dmu, nbd, etc) will not work. However, if you start the cowd daemon ahead of time and point your domain''s disk at the target device (/dev/mapper/something), then it should work. Note that qemu-dm should be able to use qcow files like qemu does, so that may be the best option for you, if you''re mostly interested in HVM domains. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > However, if you start the cowd daemon ahead of timeMy current dom0 was compiled from xen-3.0.2-2 source + dm patches. I cannot find the cowd daemon. I wonder if it is something I need to compile separately. and point your> domain''s disk at the target device (/dev/mapper/something), then it > should work.Which device do you mean for the target device? Previously, my installation configuration file was like disk ["file:/xenimages/windowsbase.img,ioemu:hda,w" ]. Then, I changed to disk ["dmu:dscow:/tmp/windowsbase.dscow:/xenimages/windowsbase.img,ioemu:hda,w" ]. Is the /tmp/windowsbase.dscow what you meant? Thank you. Note that qemu-dm should be able to use qcow files like qemu does, so> that may be the best option for you, if you''re mostly interested in > HVM domains. > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> My current dom0 was compiled from xen-3.0.2-2 source + dm OS> patches. I cannot find the cowd daemon. I wonder if it is OS> something I need to compile separately. If you applied the dm-userspace patches to your xen tree and either rebuilt and installed the whole tree, or at least the tools part, you should have "dscow_tool" and "cowd" binaries on your system. If you don''t see them, check in the tools/ directory of your tree OS> Which device do you mean for the target device? Previously, my OS> installation configuration file was like disk = ["file:/xenimages/ OS> windowsbase.img,ioemu:hda,w" ]. Then, I changed to disk OS> ["dmu:dscow:/tmp/ OS> windowsbase.dscow:/xenimages/windowsbase.img,ioemu:hda,w" ]. Is OS> the /tmp/ windowsbase.dscow what you meant? Do this: # dscow_tool -c /xenimages/windowsbase.dscow /xenimages/windowsbase.img Which will create the cow file. Then do: # cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscow Which will create a /dev/mapper/windowsbase device. Any writes to this device will be stored in the .dscow file; the .img file will remain untouched. Then, configure your domain to use the new device with something like this: disk = [ ''/dev/mapper/windowsbase,ioemu:hda,w'' ] (I''m not all that familiar with HVM config files, so adjust the above line as appropriate) Note that all the above assumes you have the dm-user.ko module loaded. If you built and installed Xen with the dm-userspace patches, you should be able to just do: # modprobe dm-user -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thank you very much for your help. Which version of Xen source are you using for those patches? I''ve been working on it but I still cannot get it successfully patched and compiled. Thank you, On 9/28/06, Dan Smith <danms@us.ibm.com> wrote:> > OS> My current dom0 was compiled from xen-3.0.2-2 source + dm > OS> patches. I cannot find the cowd daemon. I wonder if it is > OS> something I need to compile separately. > > If you applied the dm-userspace patches to your xen tree and either > rebuilt and installed the whole tree, or at least the tools part, you > should have "dscow_tool" and "cowd" binaries on your system. If you > don''t see them, check in the tools/ directory of your tree > > OS> Which device do you mean for the target device? Previously, my > OS> installation configuration file was like disk = ["file:/xenimages/ > OS> windowsbase.img,ioemu:hda,w" ]. Then, I changed to disk > OS> ["dmu:dscow:/tmp/ > OS> windowsbase.dscow:/xenimages/windowsbase.img,ioemu:hda,w" ]. Is > OS> the /tmp/ windowsbase.dscow what you meant? > > Do this: > > # dscow_tool -c /xenimages/windowsbase.dscow /xenimages/windowsbase.img > > Which will create the cow file. Then do: > > # cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscow > > Which will create a /dev/mapper/windowsbase device. Any writes to > this device will be stored in the .dscow file; the .img file will > remain untouched. Then, configure your domain to use the new device > with something like this: > > disk = [ ''/dev/mapper/windowsbase,ioemu:hda,w'' ] > > (I''m not all that familiar with HVM config files, so adjust the above > line as appropriate) > > Note that all the above assumes you have the dm-user.ko module > loaded. If you built and installed Xen with the dm-userspace patches, > you should be able to just do: > > # modprobe dm-user > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> Which version of Xen source are you using for those patches? The patches are always generated against the latest version of xen-unstable at the time. OS> I''ve been working on it but I still cannot get it successfully OS> patched and compiled. What kinds of issues are you having? Build problems? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Finally, I''ve got the dscow_tool & cowd binary files. Yet, I have another question. Is there any limitation of the size of image that dscow_tool can create? Because I successfully created dscow image from 1GB image or smaller image but 2.1 GB. I''ve got the error "segmentation fault" for 2.1GB image. Thank you. On 9/28/06, Dan Smith <danms@us.ibm.com> wrote:> > OS> My current dom0 was compiled from xen-3.0.2-2 source + dm > OS> patches. I cannot find the cowd daemon. I wonder if it is > OS> something I need to compile separately. > > If you applied the dm-userspace patches to your xen tree and either > rebuilt and installed the whole tree, or at least the tools part, you > should have "dscow_tool" and "cowd" binaries on your system. If you > don''t see them, check in the tools/ directory of your tree > > OS> Which device do you mean for the target device? Previously, my > OS> installation configuration file was like disk = ["file:/xenimages/ > OS> windowsbase.img,ioemu:hda,w" ]. Then, I changed to disk > OS> ["dmu:dscow:/tmp/ > OS> windowsbase.dscow:/xenimages/windowsbase.img,ioemu:hda,w" ]. Is > OS> the /tmp/ windowsbase.dscow what you meant? > > Do this: > > # dscow_tool -c /xenimages/windowsbase.dscow /xenimages/windowsbase.img > > Which will create the cow file. Then do: > > # cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscow > > Which will create a /dev/mapper/windowsbase device. Any writes to > this device will be stored in the .dscow file; the .img file will > remain untouched. Then, configure your domain to use the new device > with something like this: > > disk = [ ''/dev/mapper/windowsbase,ioemu:hda,w'' ] > > (I''m not all that familiar with HVM config files, so adjust the above > line as appropriate) > > Note that all the above assumes you have the dm-user.ko module > loaded. If you built and installed Xen with the dm-userspace patches, > you should be able to just do: > > # modprobe dm-user > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Finally, I''ve got the dscow_tool & cowd binary files. However, when
I did
"dscow_tool -c /xenimages/windowsbase.dscow
/xenimages/windowsbase.img", I
got the segmentation fault error. The windowsbase.img is about 2.1GB.
Surprisingly, I didn''t get any error when I tried with an image less
than
1.1GB. This is what I got from gdb
Program received signal SIGSEGV, Segmentation fault.
_dscow_write_disk_header (dscow=0x804c050) at dscow_ops.c:116
116 if (dscow->dirty_bitmaps[i]) {
Do you know what the problem is? Thank you.
On 9/29/06, Dan Smith <danms@us.ibm.com> wrote:>
> OS> Which version of Xen source are you using for those patches?
>
> The patches are always generated against the latest version of
> xen-unstable at the time.
>
> OS> I''ve been working on it but I still cannot get it
successfully
> OS> patched and compiled.
>
> What kinds of issues are you having? Build problems?
>
> --
> Dan Smith
> IBM Linux Technology Center
> Open Hypervisor Team
> email: danms@us.ibm.com
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
OS> Finally, I''ve got the dscow_tool & cowd binary files. Yet, I have OS> another question. Is there any limitation of the size of image OS> that dscow_tool can create? Because I successfully created dscow OS> image from 1GB image or smaller image but 2.1 GB. I''ve got the OS> error "segmentation fault" for 2.1GB image. No, there is not a size limit. However, some earlier versions did have some issues which caused some problems on large images. Those have since been fixed. You might try the latest version of the kernel module and tools that are in the development tree: http://static.danplanet.com/hg/dm-userspace/ Note that you *must* rebuild the kernel module and both cowd and dscow_plugin if you move to the newer version. This should be easy to do outside of your xen tree: # cd dm-userspace/module # cp dm-userspace.h /lib/modules/`uname -r`/build/include/linux # make # insmod ./dm-user.ko # cd../tools/cowd # ./autogen && ./configure --enable-internal-dmu # make && make install We have a tree on xenbits now. Eventually, we will push an updated version of the Xen tree with the latest patches integrated directly. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > > It would help (a little bit) to know the value and type of i, and the > declaration of the dscow struct... >uint32_t i; struct dscow { struct dscow_disk_header header; uint64_t blocks; uint32_t *bitmap; uint32_t bitmap_count; uint32_t *dirty_bitmaps; char *base_filename; int fd; int dirty; }; That''s not to say that it''s possible from this to determine what the correct> values should be or something, but at least it would help a little bit. The > fact that it fails at 2.1GB tends to indicate that it''s a 2^31 byte > boundary problem, which could potentially be fixed with using unsigned > rather than signed integer [give you 4GB]. >I''ve tried several scenarioes: 2048000000 bytes (2.0 GB) works fine. 3221225472 bytes (3.2 GB) gave me seg fault. 4096000000 bytes (4.1 GB) gave me seg fault again. Is this on a 32- or 64-bit system?>My hardware is capable of 64 bit. However, I''m running 32 bit ubuntu 6.06Dapper. --> Mats > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > You might try the latest version of the kernel module and tools that > are in the development tree: > > http://static.danplanet.com/hg/dm-userspace/ > > Note that you *must* rebuild the kernel module and both cowd and > dscow_plugin if you move to the newer version. This should be easy to > do outside of your xen tree: > > # cd dm-userspace/module > # cp dm-userspace.h /lib/modules/`uname -r`/build/include/linux > # make > # insmod ./dm-user.ko > # cd../tools/cowd > # ./autogen && ./configure --enable-internal-dmu > # make && make installI did all that. With this dscow_tool & cowd binaries, I still have got the same problem. However, the seg fault happens in slightly different position. Program received signal SIGSEGV, Segmentation fault. dscow_create (filename=0x0, base=0xbfe1099f "/xenimages/test.img", block_size=0) at dscow_ops.c:349 349 handle->dirty_bitmaps[i] = 1; (gdb) print i $1 = 0 And i is declared in int. -------------------------------- struct dscow { struct dscow_disk_header header; uint64_t blocks; uint32_t *bitmap; uint32_t bitmap_count; uint32_t *dirty_bitmaps; char *base_filename; int fd; int dirty; }; This image size is 4096000000 bytes (4.1 GB). Thank you. We have a tree on xenbits now. Eventually, we will push an updated> version of the Xen tree with the latest patches integrated directly. > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I know the problem is. This line failed: handle->dirty_bitmaps = calloc(handle->bitmap_count, sizeof(uint32_t)); Calloc failed to allocate the dirty_bitmaps. Is that because it''s out of heap memory? Thanks. On 9/29/06, Orathai Sukwong <kobkob@gmail.com> wrote:> > You might try the latest version of the kernel module and tools that > > are in the development tree: > > > > http://static.danplanet.com/hg/dm-userspace/ > > > > Note that you *must* rebuild the kernel module and both cowd and > > dscow_plugin if you move to the newer version. This should be easy to > > do outside of your xen tree: > > > > # cd dm-userspace/module > > # cp dm-userspace.h /lib/modules/`uname -r`/build/include/linux > > # make > > # insmod ./dm-user.ko > > # cd../tools/cowd > > # ./autogen && ./configure --enable-internal-dmu > > # make && make install > > > > I did all that. With this dscow_tool & cowd binaries, I still have got > the same problem. However, the seg fault happens in slightly different > position. > > Program received signal SIGSEGV, Segmentation fault. > dscow_create (filename=0x0, base=0xbfe1099f "/xenimages/test.img", > block_size=0) at dscow_ops.c:349 > 349 handle->dirty_bitmaps[i] = 1; > (gdb) print i > $1 = 0 > > > And i is declared in int. > -------------------------------- > struct dscow { > struct dscow_disk_header header; > > uint64_t blocks; > uint32_t *bitmap; > uint32_t bitmap_count; > uint32_t *dirty_bitmaps; > char *base_filename; > > int fd; > int dirty; > }; > > This image size is 4096000000 bytes (4.1 GB). > > Thank you. > > > > We have a tree on xenbits now. Eventually, we will push an updated > > version of the Xen tree with the latest patches integrated directly. > > > > -- > > Dan Smith > > IBM Linux Technology Center > > Open Hypervisor Team > > email: danms@us.ibm.com > > > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> I did all that. With this dscow_tool & cowd binaries, I still OS> have got the same problem. However, the seg fault happens in OS> slightly different position. I noticed, as I just tried this on a 32-bit machine and I see the failure. I assume you''re on a 32-bit machine as well? I''ll fix it up and push a changeset in a bit. Thanks for spotting this! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Please let me know when you finish fixing it. Hope it''ll be done soon. I''m really this thing to work. Thank you. On 9/29/06, Dan Smith <danms@us.ibm.com> wrote:> > OS> I did all that. With this dscow_tool & cowd binaries, I still > OS> have got the same problem. However, the seg fault happens in > OS> slightly different position. > > I noticed, as I just tried this on a 32-bit machine and I see the > failure. I assume you''re on a 32-bit machine as well? > > I''ll fix it up and push a changeset in a bit. Thanks for spotting > this! > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> Please let me know when you finish fixing it. Hope it''ll be done OS> soon. I''m really this thing to work. Thank you. Ok, I pushed a fix out to the development repo. See if that fixes it for you. I verified that creating the dscow is fixed, so I think it should be ok. If not, let me know. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thank you. It works fine. Now I have a new problem:> cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscowFailed to load libcowd_--sync=a.so: libcowd_--sync=a.so: cannot open shared object file: No such file or directory Loading --sync=a failed: (null) Failed to initialize plugin: --sync=a I have "libcowd_null.a libcowd_qcow.la libcowd_dscow.a libcowd_null.la libcowd_qcow.so libcowd_dscow.la libcowd_null.so libcowd_qcow.so.0 libcowd_dscow.so libcowd_null.so.0 libcowd_qcow.so.0.0.0 libcowd_dscow.so.0 libcowd_null.so.0.0.0" in /usr/local/lib. Do I have to set path somewhere? Thank you. On 9/29/06, Dan Smith <danms@us.ibm.com> wrote:> > OS> Please let me know when you finish fixing it. Hope it''ll be done > OS> soon. I''m really this thing to work. Thank you. > > Ok, I pushed a fix out to the development repo. See if that fixes it > for you. I verified that creating the dscow is fixed, so I think it > should be ok. If not, let me know. > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscowThe syntax is "-p dscow --sync=a". In the above line, it thinks you want to load the --sync plugin. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
You''re right. Here''s what I got # cowd -p dscow --sync=a windowsbase /xenimages/windowsbase.dscow ioctl: LOOP_SET_FD: Device or resource busy device-mapper: reload ioctl failed: Invalid argument Failed to run device-mapper command! Failed to create DM device syslog: Oct 2 11:34:36 kernel: device-mapper: unknown target type Oct 2 11:34:36 kernel: device-mapper: error adding target to table What''s wrong? The file /xenimages/windowsbase.dscow does exist. Thank you. On 10/2/06, Dan Smith <danms@us.ibm.com> wrote:> > >> cowd -p --sync=a dscow windowsbase /xenimages/windowsbase.dscow > > The syntax is "-p dscow --sync=a". In the above line, it thinks you > want to load the --sync plugin. > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I killed all cowd instance. When I did "losetup -d /dev/loop0", I got "ioctl: LOOP_CLR_FD: Device or resource busy." Then I tried #losetup /dev/loop0 /dev/loop0: [0803]:2981891 (/xenimages/windowsbase.img) # losetup /dev/loop1 /dev/loop1: [0803]:2981898 (/xenimages/windowsbase.dscow) # cowd -p dscow --sync=a windowsbase /xenimages/windowsbase.dscow ioctl: LOOP_SET_FD: Device or resource busy ioctl: LOOP_SET_FD: Device or resource busy ioctl: LOOP_SET_FD: Device or resource busy ioctl: LOOP_SET_FD: Device or resource busy ioctl: LOOP_SET_FD: Device or resource busy device-mapper: create ioctl failed: Device or resource busy Failed to run device-mapper command! Failed to create DM device And "fdisk -l" didn''t show /dev/mapper. Thank you. On 10/2/06, Dan Smith <danms@us.ibm.com> wrote:> > OS> Even though I did losetup -f, I still got the same error. > > Try doing "losetup -d /dev/loopX" for X between 0 and 3, just to make > sure they''re disconnected. Make sure all cowd instances are stopped > first, though. > > However, that loop error is normal in some cases. After starting, see > if cowd is running. If so, try to access the device in /dev/mapper > (fdisk -l should show a partition listing I think). > > -- > Dan Smith > IBM Linux Technology Center > Open Hypervisor Team > email: danms@us.ibm.com > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Even though I don''t see /dev/mapper/windowsbase listed, it works. Despite that, some settings, e.g. colors, was a bit weird. Yet I have some questions. Why is the .dscow file the same size as the .img file when originally created? We didn''t copy the entire .img file, did we? If not, what originally are in the .dscow file when created? If the .dscow file is originally empty, after used (xm create->modify->shut it down), is there a way to delete the changes in the .dscow file without openning up the domain? We use /dev/mapper to map any further modifications onto the .dscow file, right? And /dev/mapper/ would be changed every time we modify on the .dscow file, right? Thank you very much. On 10/3/06, Orathai Sukwong <kobkob@gmail.com> wrote:> > I killed all cowd instance. When I did "losetup -d /dev/loop0", I got > "ioctl: LOOP_CLR_FD: Device or resource busy." Then I tried > > #losetup /dev/loop0 > /dev/loop0: [0803]:2981891 (/xenimages/windowsbase.img) > # losetup /dev/loop1 > /dev/loop1: [0803]:2981898 (/xenimages/windowsbase.dscow) > # cowd -p dscow --sync=a windowsbase /xenimages/windowsbase.dscow > ioctl: LOOP_SET_FD: Device or resource busy > ioctl: LOOP_SET_FD: Device or resource busy > ioctl: LOOP_SET_FD: Device or resource busy > ioctl: LOOP_SET_FD: Device or resource busy > ioctl: LOOP_SET_FD: Device or resource busy > device-mapper: create ioctl failed: Device or resource busy > Failed to run device-mapper command! > Failed to create DM device > > And "fdisk -l" didn''t show /dev/mapper. Thank you. > > On 10/2/06, Dan Smith < danms@us.ibm.com> wrote: > > > > OS> Even though I did losetup -f, I still got the same error. > > > > Try doing "losetup -d /dev/loopX" for X between 0 and 3, just to make > > sure they''re disconnected. Make sure all cowd instances are stopped > > first, though. > > > > However, that loop error is normal in some cases. After starting, see > > if cowd is running. If so, try to access the device in /dev/mapper > > (fdisk -l should show a partition listing I think). > > > > -- > > Dan Smith > > IBM Linux Technology Center > > Open Hypervisor Team > > email: danms@us.ibm.com > > > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
OS> Why is the .dscow file the same size as the .img file when OS> originally created? It is a sparse file. It looks like it''s the same size as the .img, but it actually takes up only the amount of space it needs to store the data you''ve written to it. It is not an ideal format for file-based images, but it does work. It was mostly created as a simple format to use while developing the rest of the system. OS> create->modify->is there a way to delete the changes in the .dscow OS> create->modify->file without openning up the domain? You can just delete the dscow and recreate it to abandon the changes. OS> We use /dev/mapper to map any further modifications onto the OS> .dscow file, right? And /dev/mapper/ would be changed every time OS> we modify on the .dscow file, right? I''m not sure what you mean. The /dev/mapper/foo device is a pseudo device that redirects writes to the dscow file. Subsequent reads to /dev/mapper/foo show the changed version (reading the changes from the dscow file). -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users