Thanks, for the heads up. Added a issue for 4.6 to look at this http://dev.opennebula.org/issues/2658
Cheers Ruben On Mon, Jan 13, 2014 at 5:28 PM, Gareth Bult <[email protected]> wrote: > Ok, sounds good .. could I also draw your attention to the "deploy" > script, which is the other > script I need to modify .. my version looks like this; > > -- > > mkdir -p `dirname $domain` > cat > $domain > > logger "DEPLOY :: /var/lib/one/remotes/hooks/vdc/deploy.py $domain" > /var/lib/one/remotes/hooks/vdc/deploy.py $domain > > data=`virsh --connect $LIBVIRT_URI create $domain` > > -- > > Deploy does three relatively critical things you may wish to consider; > > a. adds the "sharable" flag to the libvirt config - without this libvirt > won't live migrate (on the latest versions of libvirt) > b. adds "error_policy=stop" to ensure the VM pauses in the case of an IO > error, which lets you fix the IO issue, then unpause it > c. adds "discard=unmap", which you need in order for KVM to support TRIM > requests properly > (we use TRIM to allow a VM to pass references to unused space to the > back-end storage so it can be released back to the OS) > > If it's of any use, you're more than welcome to use my deploy.py script .. > for what it does it seems fairly concise .. :) > > #!/usr/bin/python > > import xml.etree.ElementTree as ET > from sys import argv > > original = ET.parse(argv[1]) > params = original.findall(".//disk") > for p in params: > if p.get('device') == 'disk': p.insert(0,ET.Element("shareable",{})) > > params = original.findall(".//driver") > for p in params: > if p.get('type') == 'raw': > p.set("error_policy","stop") > p.set("discard","unmap") > > original.write(argv[1]) > > Regards, > Gareth. > > > -- > *Gareth Bult* > “The odds of hitting your target go up dramatically when you aim at it.” > See the status of my current project at http://vdc-store.com > > > ------------------------------ > *From: *"Ruben S. Montero" <[email protected]> > *To: *"Gareth Bult" <[email protected]> > *Cc: *[email protected] > *Sent: *Monday, 13 January, 2014 3:41:50 PM > *Subject: *Re: [one-dev] Live migration / recovery > > Totally agree, in fact we've seen this in the past. > > This is fairly easy to add, one_vmm_exec.rb includes a pseudo-dsl to > specify the actions, each action includes a fail action. Looking at the > code we have also to roll-back the networking configuration on the target > host. > > Added a new issue for this. In the meantime we can just use the previous > workaround. > > http://dev.opennebula.org/issues/2633 > > > > On Mon, Jan 13, 2014 at 2:59 PM, Gareth Bult <[email protected]> wrote: > >> Ok, this almost seems too easy ... :) >> >> What I was trying to avoid was more tweaking of ON files when installing >> VDC. >> >> The issue I see is that each time someone upgraded ON, they will >> potentially have a chain of >> small patches to apply ... if I supply a few small patches based on "if >> <vdc installed> - do something extra" >> would you include these in the stock scripts?? >> >> Gareth. >> >> -- >> *Gareth Bult* >> “The odds of hitting your target go up dramatically when you aim at it.” >> See the status of my current project at http://vdc-store.com >> >> >> ------------------------------ >> *From: *"Ruben S. Montero" <[email protected]> >> *To: *"Gareth Bult" <[email protected]> >> *Cc: *[email protected] >> *Sent: *Sunday, 12 January, 2014 10:36:30 PM >> *Subject: *Re: [one-dev] Live migration / recovery >> >> Hi Gareth >> >> As the migrate script can be easily updated we do not provide any hook >> for that. I'd go to kvm/migrate, and do a simple if [ $? ... after the >> virsh command to kill the cache on the target host. >> >> Cheers >> >> Ruben >> >> >> On Thu, Dec 19, 2013 at 12:54 PM, Gareth Bult <[email protected]> wrote: >> >>> Hi, >>> >>> I implemented live migration for the VDC driver a few weeks back and on >>> the whole it seems to work >>> quite well. The "premigrate" script creates a cache instance on the >>> target server and puts the source >>> cache into proxy mode, then the "postmigrate" script kills the original >>> cache instance. >>> >>> Problem :: if the migration fails, I'm left with a running cache on both >>> the source and target servers, with >>> the source cache in proxy mode. I have a 1-line CLI command to revert >>> the issue, but I need to hook into >>> the system in order to call it. >>> >>> How to do I do this, I guess effectively I need something like >>> "postmigrate_fail" .. ??? >>> >>> tia >>> Gareth. >>> >>> -- >>> *Gareth Bult* >>> “The odds of hitting your target go up dramatically when you aim at it.” >>> >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org >>> >>> -- >>> <http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org> >>> -- >>> Ruben S. Montero, PhD >>> Project co-Lead and Chief >>> Architect<http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org> >>> OpenNebula - Flexible Enterprise Cloud Made Simple >>> <http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org> >>> www.OpenNebula.org | [email protected] | @OpenNebula >>> >> >> > > > -- > -- > Ruben S. Montero, PhD > Project co-Lead and Chief Architect > OpenNebula - Flexible Enterprise Cloud Made Simple > www.OpenNebula.org | [email protected] | @OpenNebula > > -- -- Ruben S. Montero, PhD Project co-Lead and Chief Architect OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | [email protected] | @OpenNebula
_______________________________________________ Dev mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org
