It does appear that the SRC & DEST arguments are reversed. ----- Original Message ----- From: "Ruben S. Montero" <[email protected]> To: "Gary S. Cuozzo" <[email protected]> Cc: [email protected] Sent: Monday, December 3, 2012 5:35:47 AM Subject: Re: [one-users] iSCSI recipe
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 <[email protected]> wrote: > Thanks Laurent, I'll take the same route. Also thanks for the SRC & DST tip. > > ----- Original Message ----- > From: "Laurent Grawet" <[email protected]> > To: "Gary S. Cuozzo" <[email protected]> > Cc: "Ruben S. Montero" <[email protected]>, "christopher barry" > <[email protected]>, [email protected] > 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" <[email protected]> >> To: "Laurent Grawet" <[email protected]> >> Cc: "Gary S. Cuozzo" <[email protected]>, "christopher barry" >> <[email protected]>, [email protected] >> 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 <[email protected]> >>> wrote: >>>>> Excellent, thanks. >>>>> >>>>> ________________________________ >>>>> From: "Ruben S. Montero" <[email protected]> >>>>> To: "Gary S. Cuozzo" <[email protected]> >>>>> Cc: [email protected] >>>>> 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 <[email protected]> >>>>> 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" <[email protected]> >>>>>> To: "Gary S. Cuozzo" <[email protected]> >>>>>> Cc: [email protected] >>>>>> 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 <[email protected]> >>>>>> 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" <[email protected]> >>>>>>> To: "Gary S. Cuozzo" <[email protected]> >>>>>>> Cc: [email protected] >>>>>>> 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 <[email protected]> >>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> 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 | [email protected] | @OpenNebula >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> 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 | [email protected] | @OpenNebula >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> 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 | [email protected] | @OpenNebula >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> 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 | [email protected] | @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 > [email protected] > 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 | [email protected] | @OpenNebula _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
