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:james.harper@xxxxxxxxxxxxxxxx]
Sent: 05 June 2008 12:20 AM
To: Geoff Wiener; jim burns; xen-users@xxxxxxxxxxxxxxxxxxx
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
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home