[one-users] iSCSI recipe

Sun Dec 2 06:55:17 PST 2012

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