Tomas Jelinek has posted comments on this change.
Change subject: migration: Add incoming migration semaphore
......................................................................
Patch Set 2:
(3 comments)
please set this patch a topic like "migration" - I guess much more will be
coming so it would be good to keep track.
https://gerrit.ovirt.org/#/c/45954/2/vdsm/virt/migration.py
File vdsm/virt/migration.py:
Line 54: VIR_MIGRATE_PARAM_GRAPHICS_URI = 'graphics_uri'
Line 55:
Line 56:
Line 57: mig = min(config.getint('vars', 'max_incoming_migrations'),
Line 58: caps.CpuTopology().cores())
I don't think that there is any relationship between the number
of incoming
yeah, maybe it does not need a fallback at all. But not sure how would
it than behave after update.
BTW don't you need to define it also in the config.py.in?
Line 59:
Line 60: incomingMigrations = threading.BoundedSemaphore(mig)
Line 61:
Line 62:
Line 330: dev._deviceXML, self._vm.conf, dev.custom)
Line 331: hooks.before_vm_migrate_source(self._vm._dom.XMLDesc(0),
Line 332: self._vm.conf)
Line 333:
Line 334: while True:
Why doesn't engine handle the case of too many incoming
migrations on the h
For the same reason why the VDSM has an outgoing semaphore.
Engine decides that this 10 machines should land on this VDSM and it is correct so sends
the commands. And the VDSM migrates them. Which is again correct. It just does not migrate
them in one big batch to protect itself from overload.
Line 335: # Do not measure the time spent for creating the VM on the
Line 336: # destination. In some cases some expensive operations can
Line 337: # cause the migration to get cancelled right after the
Line 338: # transfer started.
Line 347: SourceThread._ongoingMigrations.release()
Line 348: # the destination is busy with incoming migrations
Line 349: # release semaphore and give other outgoing migrations
Line 350: # a chance
Line 351: time.sleep(5)
seems very arbitrary and possibly works for short migrations, how
about lon
It is not "wait until migration finishes". It is "wait to
not to eat up all the resources and give other waiting threads a chance to get the lock
and start migrating to possibly other destinations". So I don't think it has
anything to do with how long the migration takes.
Line 352: SourceThread._ongoingMigrations.acquire()
Line 353: else:
Line 354: break
Line 355:
--
To view, visit
https://gerrit.ovirt.org/45954
To unsubscribe, visit
https://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I8952f732033ed160292b11fbc0c4deac099b2b3e
Gerrit-PatchSet: 2
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Martin Betak <mbetak(a)redhat.com>
Gerrit-Reviewer: Martin Polednik <mpolednik(a)redhat.com>
Gerrit-Reviewer: Michal Skrivanek <mskrivan(a)redhat.com>
Gerrit-Reviewer: Tomas Jelinek <tjelinek(a)redhat.com>
Gerrit-Reviewer: automation(a)ovirt.org
Gerrit-HasComments: Yes