[one-users] Access to DS for image in TM

Gary S. Cuozzo gary at isgsoftware.net
Fri Dec 28 06:36:59 PST 2012


Ruben, 
Thank you for the info. I was able to make some slight modifications to my TM driver. I tested my failover process and it works great. Simply change a few parameters in my DS template & redeploy the VM's on a different storage server. 

Looking again at the docs for storage subsystem integration, unless I am misinterpreting them it does not appear that the parameters are described correctly. For example, what I am seeing when I log arguments to the ln script is that arg3 is the VMID and arg4 is the DSID for the image. It appears the docs may need some updating. 

Thanks again, 
gary 


----- Original Message -----

From: "Gary S. Cuozzo" <gary at isgsoftware.net> 
To: "Users OpenNebula" <users at lists.opennebula.org> 
Sent: Thursday, December 27, 2012 9:13:39 AM 
Subject: Re: [one-users] Access to DS for image in TM 


Hello Ruben, 
I'm glad I asked. I must have missed something in the docs. I thought it was the system datastore of the remote host that was sent in. If it is the ID of the image DS, then I will be all set. 

Thanks! 
gary 


----- Original Message -----

From: "Ruben S. Montero" <rsmontero at opennebula.org> 
To: "Gary S. Cuozzo" <gary at isgsoftware.net> 
Cc: "Users OpenNebula" <users at lists.opennebula.org> 
Sent: Thursday, December 27, 2012 4:01:40 AM 
Subject: Re: [one-users] Access to DS for image in TM 


Hi Gary, 


The last parameter of the TM scripts is the DS_ID of the image, you could get the information by simply onedatastore show $DS_ID, and probably xpath.rb to get the SAN_HOST if you are working in a shell script. 


Note that DS_ID refers to the Datastore of the image, so for CLONE, LN ... would make sense, other operations may use the System DS as the DS_ID (e.g. DELETE). 


Is this good enough? 


Cheers 


Ruben 



On Wed, Dec 26, 2012 at 2:59 PM, Gary S. Cuozzo < gary at isgsoftware.net > wrote: 




Hello, 
Sorry this is sort of long, hope it makes sense... 

I have created customized DS & TM drivers for our NFS based storage servers. Each storage server is snap-shotted and replicated at least every hour to another server. I have a use case that I would like to be able to remap all images for a particular server quickly in the event of a failure, such as a hardware issue. 

In my DS driver, I have a parameter for SAN_HOST which is used to determine which storage server will be used to deploy the image. For my failure case, I would like to simply be able to edit the SAN_HOST parameter for the particular DS which failed and redeploy the vm's, having the images automatically go to the backup server and not have to remap them all. This would take the recovery process from several hours of manually remapping things to probably < 1 hour. 

The TM drivers don't get any information passed to them about the DS of the particular image they are working with. What I would like to do is be able to access the DS parameters for an image and use them to remap certain aspects of the image so the remapping will work. 

The obvious way I've thought of is to just use the image SOURCE and iterate through the image list in order to get a match, then go look up the associated DS. 

Is there any better way that I may be missing? My way seems a bit kludgy but I didn't think of any other way. 

Thanks in advance, 
gary 


_______________________________________________ 
Users mailing list 
Users at lists.opennebula.org 
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org 







-- 
Ruben S. Montero, PhD 
Project co-Lead and Chief Architect 
OpenNebula - The Open Source Solution for Data Center Virtualization 
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula 

_______________________________________________ 
Users mailing list 
Users at lists.opennebula.org 
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20121228/217ca66f/attachment-0002.htm>


More information about the Users mailing list