Xen devel - Jul 2007 - ''block'' script broken: wrong error message

When trying to start a virtual machine using a virtual disk from
/var/lib/vm/0/hda1.img image I am getting error response:

  INTERNAL_ERROR: Device 769 (vbd) could not be connected.
  File /var/lib/vm/0/hda1.img is loopback-mounted through /dev/loop0,
  which is mounted in a guest domain,
  and so cannot be mounted now.

The problem is that /var/lib/vm/0/hda1.img is not and was not used by anything
else. Even losetup says that:

# losetup -a
/dev/loop0: [fe04]:65729 (/var/lib/vm/1/hda1.img)
/dev/loop1: [fe04]:17097 (/etc/vm/images/1.3r5136/hda2.img)
/dev/loop10: [fe04]:65740 (/var/lib/vm/1/hda1.img)
/dev/loop100: [fe04]:17097 (/etc/vm/images/1.3r5136/hda2.img)

Please note, that ''/var/lib/vm/1/hda1.img'' (which does not
exist now and
should not be used, as the domain has been already destroy()ed several
times) and not ''/var/lib/vm/0/hda1.img'' is bound to
/dev/loop0.

I think the following part of /etc/xen/scripts/block script is responsible for
that problem:

            # Canonicalise the filename for the comparison.

            # I have seen this readlink fails because the filename given by
            # losetup is only the basename.  This cannot happen when the loop
            # device is set up through this script, because file is
            # canonicalised above, but it may happen when loop devices are set
            # up some other way.  This readlink may also conceivably fail if
            # the file backing this loop device has been removed.

            # For maximum safety, in the case that $f does not resolve, we
            # assume that $file and $f are in the same directory.

            # If you create a loopback filesystem, remove it and continue to
            # run on it, and then create another file with the same name, then
            # this check will block that -- don''t do that.

            # If you create loop devices through some other mechanism, use
            # relative filenames, and then use the same filename through this
            # script, then this check will block that -- don''t do that
either.

            f=$(readlink -f "$f" || echo $(dirname
"$file")/$(basename "$f"))

The last line effectively discards directory name for comparison ($f is
compared to $file later) if readlink of "$f" fails. In my case $f
don''t even
exists, so the directories are ignored and only basename (which is the same for
all my virtual machines) is compared.

And another thing: why are path names compared instead of inode numbers. If
image file is renamed then all the ''safety checks'' will fail
anyway. And now
they give ugly false positives as the one described by me and the others
described in the code comments above.

Greets,
	Jacek

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

> The last line effectively discards directory name for comparison ($f
is
> compared to $file later) if readlink of "$f" fails. In my case $f
don''t
> even exists, so the directories are ignored and only basename (which
is the
> same for all my virtual machines) is compared.
The current basename comparison is foul, but losetup doesn''t exactly
make it easy to do the right thing.
> And another thing: why are path names compared instead of inode
numbers.

If you know how to get the filesystem and inode numbers out of losetup,
great!

The alternative is to have xend explicitly remember what loop devices
its set up and work on the assumption that people aren''t doing things
behind its back.

Ian

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

On Wed, Jul 04, 2007 at 06:32:36PM +0100, Ian Pratt
wrote:
> > And another thing: why are path names compared instead of inode
> numbers.
> 
> If you know how to get the filesystem and inode numbers out of losetup,
> great!
# losetup -a
/dev/loop0: [fe04]:65738 (/var/lib/vm/0/hda1.img)
/dev/loop1: [fe04]:65752 (/var/lib/vm/0/hda3.img)
/dev/loop10: [fe04]:17097 (/etc/vm/images/1.3r5136/hda2.img)

# stat /var/lib/vm/0/hda1.img
File: `/var/lib/vm/0/hda1.img''
Size: 3072            Blocks: 8          IO Block: 4096   regular file
Device: fe04h/65028d    Inode: 65738       Links: 1
Access: (0660/-rw-rw----)  Uid: (  996/    vm)   Gid: (  996/    vm)
Access: 2007-07-04 15:34:22.000000000 +0200
Modify: 2007-07-04 15:33:23.000000000 +0200
Change: 2007-07-04 15:33:59.000000000 +0200

So "[fe04]" in "losetup -a" output is device id and the
number after that is
the inode number.

# rpm -q losetup
losetup-2.13-0.pre7.2.i686

So it cames from util-linux version 2.13pre7.

Greets,
        Jacek

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

> # losetup -a
> /dev/loop0: [fe04]:65738 (/var/lib/vm/0/hda1.img)
> /dev/loop1: [fe04]:65752 (/var/lib/vm/0/hda3.img)
> /dev/loop10: [fe04]:17097 (/etc/vm/images/1.3r5136/hda2.img)
> # rpm -q losetup
> losetup-2.13-0.pre7.2.i686
> 
> So it cames from util-linux version 2.13pre7.
Cool. However, this must be a relatively new feature -- losetup from
util-linux 2.12a doesn''t have the ''-a'' option.  

It would be good if someone could knock up a patch that uses the
fs:inode where available, though. 

Ian

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