[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] [Project Kronos] SR_BACKEND_FAILURE_53 when creating SR



On 23.08.2011 21:39, Sébastien Riccio wrote:


Sorry, didn't notice this before, but SMLog says this:

[3010] 2011-08-23 15:17:42.111948       SUCCESS
[3010] 2011-08-23 15:17:42.112201 ['/sbin/vgcreate', 'VG_XenStorage-c6ed11e9-8acf-3c48-93b9-10a7607f6035', '/dev/sda3']
[3010] 2011-08-23 15:17:42.209556       SUCCESS
[3010] 2011-08-23 15:17:42.209789 ['/sbin/vgchange', '-an', '--master', 'VG_XenStorage-c6ed11e9-8acf-3c48-93b9-10a7607f6035'] [3010] 2011-08-23 15:17:42.223883 FAILED: (rc 3) stdout: '', stderr: '/sbin/vgchange: unrecognized option '--master'
   Error during parsing of command line.

Obviously, --master is not a flag for vgchange..

Editing lvutil.pyc in /usr/lib/xen-common/xapi/sm gets me past this issue...

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api



I found again where I read this. Here is a copy/paste:
--
We use XAPI as the "Cluster lock manager"
essentially. There is a strict notion of ordering of events, and XAPI
always ensures that there is a single SRMaster for any shared SR. The SR
master is the only entity that modifies LVM metadata, and it
strategically refreshes slaves as necessary. Typically slaves only
operate in an LVM Read-only mode, so the LVM metadata is refreshed when
a slave needs to access a new logical volume, and the slave is only
allowed to create device-mapper nodes, never to modify the LVM metadata.

There are patches to LVM to add an explicit 'master' flag, this ensures
that non-masters never attempt to repair LVM metadata if ever it is read
and found to be inconsistent. In practice this would never happen due to
the way LVM updates its metadata and the fact that we do not allow
shared Volume Groups that span more than one LUN, however it's an
important safety catch.
--

So a patched lvm will need to be provided for debian too, for safely using
lvm on shared storage environnement ...

Sébastien

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.