Is it possible to modify the GUID associated with a ZFS volume imported into STMF? To clarify- I have a ZFS volume I have imported into STMF and export via iscsi. I have a number of snapshots of this volume. I need to temporarily go back to an older snapshot without removing all the more recent ones. I can delete the current sbd LU, clone the snapshot I want to test, and then bring that back in to sbd. The problem is that you need to use sbdadm create-lu and that creates a new GUID. (sbdadm import-lu on a clone will give you a metafile error). Is it possible to change the GUID of the newly imported volume to match the old volume (even if that means changing the guid of the old volume first)? I had hoped this could be done by dumping the stmf_sdb_lu property from zfs and setting the clones property to this value- but that does not seem to work. Changing the guid is not an option for these tests. Any ieas? -- This message posted from opensolaris.org
Don,> Is it possible to modify the GUID associated with a ZFS volume imported into STMF? > > To clarify- I have a ZFS volume I have imported into STMF and export via iscsi. I have a number of snapshots of this volume. I need to temporarily go back to an older snapshot without removing all the more recent ones. I can delete the current sbd LU, clone the snapshot I want to test, and then bring that back in to sbd. > > The problem is that you need to use sbdadm create-lu and that creates a new GUID. (sbdadm import-lu on a clone will give you a metafile error).Take a look at the command set associated with stmfadm, and you should see that it has taken on all sbdadm options, and more. I believe you are looking for the functionality associated with stmfadm offline-lu, ... online-lu. - Jim> Is it possible to change the GUID of the newly imported volume to match the old volume (even if that means changing the guid of the old volume first)? > > I had hoped this could be done by dumping the stmf_sdb_lu property from zfs and setting the clones property to this value- but that does not seem to work. > > Changing the guid is not an option for these tests. Any ieas? > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
You can try to workaround - no idea if this would really work - 0) Disable stmf and iscsi/* services 1) Create your volume''s clone 2) Rename the original live volume dataset to some other name 3) Rename the clone to original dataset''s name 4) Promote the clone - now for the system it SHOULD seem like this clone was always here with this original naming, and your current newer dataset is a cloned deviation. Hopefully this will fool STMF into using this data instead of new data, with existing GUID... 5) Enable stmf and iscsi/* services *) Tell us if it works ;) HTH, //Jim -- This message posted from opensolaris.org
I can''t actually disable the STMF framework to do this but I can try renaming things and dumping the properties from one device to another and see if it works- it might actually do it. I will let you know. -- This message posted from opensolaris.org
On 05/10/11 09:45 PM, Don wrote:> Is it possible to modify the GUID associated with a ZFS volume imported > into STMF? > > To clarify- I have a ZFS volume I have imported into STMF and export via > iscsi. I have a number of snapshots of this volume. I need to temporarily > go back to an older snapshot without removing all the more recent ones. I > can delete the current sbd LU, clone the snapshot I want to test, and then > bring that back in to sbd. > > The problem is that you need to use sbdadm create-lu and that creates a > new GUID. (sbdadm import-lu on a clone will give you a metafile error).Hi, maybe this could do: stmfadm create-lu -p guid=XXX.. Regards,
It turns out this was actually as simple as: stmfadm create-lu -p guid=XXX.. I kept looking at modify-lu to change this and never thought to check the create-lu options. Thanks to Evaldas for the suggestion. -- This message posted from opensolaris.org