Bug 345441

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.

Created attachment 338350 [details]
Check for vbd, tap & vif duplicates before attach

I've created a patch which is essentially a backport of upstream at http://xenbits.xensource.com/xen-3.1-testing.hg?rev/a654e7bc9c3f however we're not using XendConfig.py so I made modifications to XendDomainInfo.py . Also I saw no need to backport function _blkdev_name_to_number because I think the blkdev_name_to_number already defined here is good enough. Also, check for tap devices (not only vbd and vif) was added. It's been tested on my x86_64 machine and it's working fine.

Michal

Created attachment 339462 [details]
New version of my patch

This is a new version of my patch with some things fixed...

*** Bug 445589 has been marked as a duplicate of this bug. ***

Created attachment 339525 [details]
Check for duplicates and do not allow using disk devices from already running domains fix

I have created a new version of this patch that fixes BZ #445589 too. The BZ #455589 is about that we should deny attaching a disk device that is already used by a running domain.

Created attachment 339641 [details]
Updated version of my patch as described in comment #10

Well, I've been testing it and I have found some other issues that I have fixed now in new version of patch (attached now). There was an issue when attaching the same uname with different syntax, eg. when attaching file:/path/to/file with existing tap:aio:/path/to/file . I have modified my patch to get path only so if somebody wants to use an image eg. for qcow (tap:qcow:/path/to/file) and another domain uses this image as tap:aio:/path/to/file already, it's denied as well and error is returned. Also when trying to attach to another domain, the proper error message that the uname is used by another domain is returned and when sxpr is empty, it's still checking for uname duplicates in the global context not to use virtual block device that's already used by other guest The scenario written in BZ #445589 (formerly BZ #223259) has been tested and it's not possible to run the domain if using vbd/tap device already defined for another guest. So this is generally BZ #345441 but is solves BZ #445589 as well.

Michal

Created attachment 341424 [details]
New version of my patch allowing local migrations as well

This is the updated version of my patch to allow local migrations as well. It  disables check for duplicates in the case of migrating domain.

*** Bug 444415 has been marked as a duplicate of this bug. ***

Created attachment 342453 [details]
New version taking access mode into account

Hi, this is a new version of my patch allowing both local migrations and also taking new drive device access mode into account.

Michal

Created attachment 343447 [details]
Updated version of my patch

I hope this is final version of patch for this. There are not only read-only, read-write access modes like I thought but the modes there can be read-only, write-shared and write-exclusive so that this patch takes all the modes into account.

Fix built into xen-3.0.3-86.el5

~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Could you please give out test steps for reproduce this bug ? Thanks a lot

I believe the way to reproduce this is to assign two vif devices with the same MAC address.  In 5.3, this would be allowed, and it would confuse the networking.  In 5.4, this should be disallowed on domain creation so the user never gets into trouble.

There's a similar check for vbd stuff, but from a quick glance at the patch I can't quite understand how to trigger that situation.

Chris Lalancette

For vbds, you should be able to trigger this bug, e.g. by trying to attach a single image file as a vbd to more than one guest. However, there are more options here... you can safely attach the same image to more than one guest if all of them sees that as a read-only device or in a shared rw mode (w! in domain's configuration); you can't attach it as read-write in one guest and read-only in another one.

Verified on xen-3.0.3-91.el5 PASS

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1328.html