Xen devel - Apr 2009 - testing that volumes are not currently attached to loopback devices

xend will not start a domain if one of the block devices is currently
mounted elsewhere, but it will not detect if the device is currently
attached to a loopback device. I wouldn''t have thought this a problem,
provided that the loop device itself wasn''t in use, but it causes all
sorts of strange things to happen.

My loop device was mounted with the following command ''losetup --offset
32256 /dev/loop4 /dev/vg00/virt-domu_name-0'', which allows me to mount
the filesystem with ntfs-3g (32256 is the offset of the partition in the
disk image).

The symptoms were that windows would BSoD shortly after login, chkdsk
always reported errors (as done under the recovery console) and changes
made in the DomU filesystem didn''t seem to stick. As soon as I
un-attached the loopback device (losetup -d) all those problems went
away. For some strange reason this didn''t result in the total
destruction of the filesystem :)

The box I''m testing this on is 3.1.x... is it fixed in any later
versions? Any idea how to detect if a volume is attached via losetup?
Any idea why this causes a problem at all?

Thanks

James

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

On Thu, Apr 09, 2009 at 10:42:58PM +1000, James Harper
wrote:
> xend will not start a domain if one of the block devices is currently
> mounted elsewhere, but it will not detect if the device is currently
> attached to a loopback device. I wouldn''t have thought this a
problem,
> provided that the loop device itself wasn''t in use, but it causes
all
> sorts of strange things to happen.
> 
> My loop device was mounted with the following command ''losetup
--offset
> 32256 /dev/loop4 /dev/vg00/virt-domu_name-0'', which allows me to
mount
> the filesystem with ntfs-3g (32256 is the offset of the partition in the
> disk image).
> 
> The symptoms were that windows would BSoD shortly after login, chkdsk
> always reported errors (as done under the recovery console) and changes
> made in the DomU filesystem didn''t seem to stick. As soon as I
> un-attached the loopback device (losetup -d) all those problems went
> away. For some strange reason this didn''t result in the total
> destruction of the filesystem :)
> 
> The box I''m testing this on is 3.1.x... is it fixed in any later
> versions? Any idea how to detect if a volume is attached via losetup?
> Any idea why this causes a problem at all?
Loop devices won''t flush out writes to disk for an arbitrary amount
of time, and of course also have read cache.

If your Xen guest  accesses the same underlying file, using direct
I/O I imagine you could be seeing inconsistent data from the file

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

> 
> Loop devices won''t flush out writes to disk for an arbitrary
amount
> of time, and of course also have read cache.
> 
> If your Xen guest  accesses the same underlying file, using direct
> I/O I imagine you could be seeing inconsistent data from the file
> 
It very nearly drove me around the bend. The boot process (bios and the
int13 bootstrap of windows) would see the ''old'' data that was
being
cached by the loopback device. The PV drivers were seeing the
''real''
data.

So I would update my PV drivers into the DomU, reboot, and get the old
ones because they were loaded by the int13 bootstrap (I didn''t know
this
at first). Once the PV drivers took over though, windows would see the
new version of the driver but didn''t care as it was already loaded, the
drivers in C:\WINDOWS\system32\drivers were definitely the new ones and
I couldn''t figure out why the old ones were still being loaded. It
nearly drove me insane I tell you!!!

I''m actually not sure that 3.3+ suffers from this problem though.
I''ve
just realised that the machine I was testing on yesterday was my 3.1.x
machine...

James



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