2:52 p.m.
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "Liron Aravot" <laravot(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Michael Kublin" <mkublin(a)redhat.com>
Sent: Monday, November 19, 2012 2:44:56 PM
Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
>
>
> ----- Original Message -----
> > From: "Liron Aravot" <laravot(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Sent: Monday, November 19, 2012 2:03:57 PM
> > Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater
> >
> > starting a new discussion thread.
> >
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > > To: "Liron Aravot" <laravot(a)redhat.com>
> > > Sent: Monday, November 19, 2012 12:42:10 PM
> > > Subject: Re: [Engine-devel] OvfAutoUpdater
> > >
> > > I think 'version' is a more standard term for the column names.
> > >
> > > Also in: 4. If succesfull - for each vm update the
> > > ovf_generation
> > > to
> > > equal the db_generation.
> > > I think you mean that the update should be to the entity
> > > version
> > > you
> > > initially selected.
> > >
> 1. I think should be version = version +1;
the version will be the
db_generation that was loaded when we loaded the vm/template.
for example - if the vm/template was updated twice between OvfUpdater runs, we will need
to increment twice - so incrementing by one will cause another unneeded ovf update for
that vm.
> 2. Now the quartz is automatic process, updateVmInSpm it is spm
> operation -it means it can trigger a reconstruct
> and spm election.
2. updateVmInSpm command would be changed so it won't
trigger failover, will add that to the wiki.
> 3. How your solution is handling a case of
> hotPlug/hotUnplug/remove/add of vm disks. vm_static is not usually
> updated.
Whenever will be a command that locks a vm/template, you will have an
option during the unlock to specify if the version need to be incremented, you'll be
able to increment it also yourself.
The HotUnPlug command does lock the vm and during endSuccesfully attempt to update the vm
in spm, so it will increment the db_version/generation instead.
Also consider snapshots & vNICs which affect the VM state.
Whatever affect the
vm state and triggers updateVmInSpm today will continue to, it can be added to flows which
don't do that today.
> 4. Reconstruct/Recovery - updateVmInSpm should be called on all
> vms,
> no matter if they were updated.
Ofcourse, it's being taken care of.
>
> > > Regards,
> > > Mike
> > >
> > > ----- Original Message -----
> > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > >
> > > > Hi all, i'll be glad if you could review the wiki page of
> > > > OvfAutoUpdater, if you have any suggestions or ideas please
> > > > let
> > > > me
> > > > know.
> > > >
> > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater
> > > >
> > > > short preview from the wiki:
> > > > vm/template configurations (including disks info) are stored
> > > > on
> > > > the
> > > > master storage domain for backup purposes, import/export and
> > > > also
> > > > to
> > > > provide the abillity to run VMs without having a running
> > > > engine/db.
> > > > Currently ovf update is done synchronously when performing
> > > > various
> > > > operations on vms/templates - update, save, adding/removing a
> > > > disk,
> > > > etc. What's more, currently updating the ovf (updateVM vdsm
> > > > call)
> > > > is
> > > > usually done within a transcation.
> > > >
> > > > The idea behined OvfAutoUpdater is to perform batch ovf
> > > > update
> > > > operations that aggregate all outstanding updates per data
> > > > center.
> > > > These updates will be done in specifed time intervals which
> > > > will
> > > > reduce XML-RPC calls and will enable the removal of this
> > > > syncronous
> > > > vdsm call from all over the code.
> > > >
> > > > Thanks,
> > > > Liron Aravot.
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>