WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] 'block' script broken: wrong error message

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] 'block' script broken: wrong error message
From: Jacek Konieczny <jajcus@xxxxxxxxxx>
Date: Wed, 4 Jul 2007 14:27:00 +0200
Delivery-date: Wed, 04 Jul 2007 05:24:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>