[one-users] iSCSI recipe

Ruben S. Montero rsmontero at opennebula.org
Mon Dec 3 02:35:47 PST 2012


Hi

Yes the pre-post scripts are those of the system datastore. In fact,
you are dealing with disk images inside the system datastore. I agree
this can be misleading, but think that in general you may have images
from different datastores that may need different things.

So the pre-post scripts are those of the system data-store, but you do
not follow the system datastore type (i.e. iSCSI things do fit in the
shared pre/post scripts). Also note that you should use the VM
template to iterate through the disks and perform the pre-post
operations over them.

About SRC/DST arguments, do you refer to the src and dst hosts, right?
is that a bug that we need to address?

Cheers and thank you for your great feedback!

Ruben



On Sun, Dec 2, 2012 at 3:55 PM, Gary S. Cuozzo <gary at isgsoftware.net> wrote:
> Thanks Laurent, I'll take the same route.  Also thanks for the SRC & DST tip.
>
> ----- Original Message -----
> From: "Laurent Grawet" <laurent.grawet at uclouvain.be>
> To: "Gary S. Cuozzo" <gary at isgsoftware.net>
> Cc: "Ruben S. Montero" <rsmontero at opennebula.org>, "christopher barry" <cbarry at rjmetrics.com>, users at lists.opennebula.org
> Sent: Sunday, December 2, 2012 5:53:01 AM
> Subject: Re: [one-users] iSCSI recipe
>
> Hi Gary,
>
> On 02/12/12 07:44, Gary S. Cuozzo wrote:
>> Hi Ruben,
>> I'm finally back to work on my opennebula project.  I just upgraded to 3.8.1 and starting to modify my drivers to use the new pre/postmigrate scripts.  I see they only get called for the TM of the system datastore ("shared" in my case).  Is there a reason that the pre/post scripts can't be called on the TM for the driver of the particular disk that is being migrated?  I have 2 different drivers, a ZFS-iSCSI and a ZFS-NFS driver that both need to perform tasks before & after migration.  If one called the pre/post script for the specific TM, I could put all the logic together for each driver.
>>
>> I guess what I could do for now is modify the shared driver to check the TM of the disk and then call the appropriate driver script from there.
>>
>> What do you think?
>>
>> Thanks for adding the feature.
>> gary
>
> There is a workaround for this. I have put the pre/post scripts inside
> my driver directory. I call them from the pre/post scripts of the system
> datastore. Then I check TM_MAD inside my scripts using DS_ID.
> One thing I have noticed, SRC and DST args are swapped.
>
> Cheers,
>
> Laurent
>
>>
>>
>> ----- Original Message -----
>> From: "Ruben S. Montero" <rsmontero at opennebula.org>
>> To: "Laurent Grawet" <laurent.grawet at uclouvain.be>
>> Cc: "Gary S. Cuozzo" <gary at isgsoftware.net>, "christopher barry" <cbarry at rjmetrics.com>, users at lists.opennebula.org
>> Sent: Wednesday, October 31, 2012 6:41:44 PM
>> Subject: Re: [one-users] iSCSI recipe
>>
>> Hi
>>
>> Please note that the post/pre-migrate scripts are those from the
>> system datastore. Probably, they should be put in shared or ssh dir
>> and not in iscsi.
>>
>>
>> The description of the arguments are in here:
>> http://opennebula.org/documentation:rel3.8:sd
>>
>> If you need to iterate over the disks in the template, you may be need
>> to use ruby or pythonn for this script. Or, if you assume that there
>> are no more than,let say 5 disks,you can get the first 5 diks using
>> VM/TEMPLATE/DISK[DISK_ID=0] and so on and work on them if they are
>> defined....
>>
>>
>> Cheers
>>
>>
>> Ruben
>>
>>
>>> On Fri, Aug 17, 2012 at 9:43 AM, Gary S. Cuozzo <gary at isgsoftware.net>
>>> wrote:
>>>>> Excellent, thanks.
>>>>>
>>>>> ________________________________
>>>>> From: "Ruben S. Montero" <rsmontero at opennebula.org>
>>>>> To: "Gary S. Cuozzo" <gary at isgsoftware.net>
>>>>> Cc: users at lists.opennebula.org
>>>>> Sent: Thursday, August 16, 2012 7:19:23 PM
>>>>>
>>>>> Subject: Re: [one-users] iSCSI recipe
>>>>>
>>>>> Ok
>>>>>
>>>>> Know I see the point. We are doing something similar for attaching/detaching
>>>>> an specific script is executed before and after the hypervisor. So I guess
>>>>> this could be added. I've filled an issue for this and plan it in future
>>>>> versions
>>>>>
>>>>> http://dev.opennebula.org/issues/1419
>>>>>
>>>>> Meanwhile, as you probably had already found out, you can modify the migrate
>>>>> script to embed those "TM scripts".
>>>>>
>>>>> Cheers
>>>>>
>>>>> Ruben
>>>>>
>>>>> On Thu, Aug 16, 2012 at 5:40 PM, Gary S. Cuozzo <gary at isgsoftware.net>
>>>>> wrote:
>>>>>> Is there a reason that ONE can't call a TM script with the source host,
>>>>>> dest host, vm template, etc. when the migrate command is executed?
>>>>>>
>>>>>> While ONE can't orchestrate the migration, it can at least notify the TM
>>>>>> of the migration in advance.  That would allow me to grab the info I need
>>>>>> from the template and fire off the login or rescan on the dest host.  ONE
>>>>>> has got to know this info in order to even notify libvirt/KVM to do the
>>>>>> migration.  So just call a TM script before issuing the libvirt command and
>>>>>> abort if the script returns error.
>>>>>>
>>>>>> Logout is not as critical to me.  Worst case I have some hosts which iSCSI
>>>>>> sessions which are not in use.  The ideal scenario would be to be able to
>>>>>> have some sort of TM script that gets called after ONE detects successful
>>>>>> migration, but I could work around that on my own if it were not the case.
>>>>>>
>>>>>> ________________________________
>>>>>> From: "Ruben S. Montero" <rsmontero at opennebula.org>
>>>>>> To: "Gary S. Cuozzo" <gary at isgsoftware.net>
>>>>>> Cc: users at lists.opennebula.org
>>>>>> Sent: Thursday, August 16, 2012 11:28:27 AM
>>>>>>
>>>>>> Subject: Re: [one-users] iSCSI recipe
>>>>>>
>>>>>> Note that OpenNebula cannot orchestrate the two libvirt/KVM hypervisors
>>>>>> doing the migration. When the first host is ready to stop running the VM
>>>>>> (memory has been sent to the second hypervisor, etc..) it executes the hook
>>>>>> (logout from the iSCSI server) and just right before starting rhe VM in the
>>>>>> second host the hook (login in the iSCSI server) is run. There is nothing we
>>>>>> can do to hook in that process.
>>>>>>
>>>>>> We could however, include such scripts as part of the TM, distribute them
>>>>>> in the hosts, and put them in the right places...
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 16, 2012 at 1:48 PM, Gary S. Cuozzo <gary at isgsoftware.net>
>>>>>> wrote:
>>>>>>> Thanks.  While I understand that the login/logout needs to happen on the
>>>>>>> host systems, I think that if ONE had it's own hook or, better IMO, a TM
>>>>>>> script that could be called before/after migration, the functionality could
>>>>>>> be contained within the drivers themselves.  Then I could just take my code
>>>>>>> (which is now sprinkled across several host machines) and put it in the TM
>>>>>>> where I think it better fits.  My DS/TM already make remote calls via SSH to
>>>>>>> the SAN & vm hosts, so this would still fit the model pretty nicely.
>>>>>>>
>>>>>>> I seem to remember that if the similar events for non-persistent images
>>>>>>> were called for persistent ones, I would be able to accomplish what I want.
>>>>>>>
>>>>>>> Let me know your thoughts.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> gary
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>> From: "Ruben S. Montero" <rsmontero at opennebula.org>
>>>>>>> To: "Gary S. Cuozzo" <gary at isgsoftware.net>
>>>>>>> Cc: users at lists.opennebula.org
>>>>>>> Sent: Thursday, August 16, 2012 5:55:57 AM
>>>>>>> Subject: Re: [one-users] iSCSI recipe
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> For live-migrations the supported procedure is the libvirt hook, note
>>>>>>> that live migrations requires a close synchronization between the image
>>>>>>> movements, memory movements and the hypervisors. OpenNebula cannot perform
>>>>>>> the login/logout from the iSCSI sessions there. Cold migrations are handled
>>>>>>> by opennebula as part of the save and restore commands.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Ruben
>>>>>>>
>>>>>>> On Sun, Aug 12, 2012 at 4:41 AM, Gary S. Cuozzo <gary at isgsoftware.net>
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>> * Each host needs to attach to all iSCSI targets that are needed by
>>>>>>>>> guests running on the host. It's not entirely clear to me if ONE
>>>>>>>>> handles
>>>>>>>>> all that or not (assuming it does).
>>>>>>>>>
>>>>>>>>> ONE handles this by login/logout in an iSCSI session as needed
>>>>>>>> My iSCSI setup uses a target for each virtual server, and multiple LUN's
>>>>>>>> per target (if the server has multiple disks).  I developed a custom driver
>>>>>>>> for it.  I don't know if I have a shortcoming in my driver, or maybe a
>>>>>>>> config issue on ONE, but I found that ONE did NOT handle the login/logout on
>>>>>>>> the host machines.  It was fine for the initial setup & deployment of the
>>>>>>>> vm, but live migrations did not cause my driver to initiate a login on the
>>>>>>>> receiving host and a logout on the transferring host.
>>>>>>>>
>>>>>>>> I ended up having to write a libvirt hook which scanned for new targets
>>>>>>>> to log them in.  It also rescanned all current targets to check if they had
>>>>>>>> new LUN's attached to them.  It works well and my vm's migrate just fine,
>>>>>>>> but I would prefer to have all this handled within ONE.
>>>>>>>>
>>>>>>>> What is the script that ONE calls in order to initiate the
>>>>>>>> logins/logouts as vm's migrate?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>
>>>
>>> --
>>> Laurent Grawet
>>> Infrastructures de production du système d'information (LS/SGSI/SIPR)
>>> Université Catholique de Louvain - UCL
>>> Tél : +32 (0)10 47 38 44
>>>
>>>
>>
>>
>> --
>> 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
>
>
> --
> Laurent Grawet
> Infrastructures de production du système d'information (LS/SGSI/SIPR)
> Université Catholique de Louvain - UCL
> Tél : +32 (0)10 47 38 44
>
>
> _______________________________________________
> 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



More information about the Users mailing list