Description of problem: Upon migration the guests clock stops counting for the duration between: pause_all_vcpus on source, resume vcpus on destination. Which depends on downtime. How reproducible: See parent BZ Bug 1230126 - qemu-kvm-rhev: guest time falls behind wall time due to latencies during migration Steps to Reproduce: 1. migrate guest 2. read guest clock, confirm it is behind real time for the duration described above (is behind real time). 3. Expected results: Guest clock should match real time. Additional info: Libvirt should issue command to resume guest upon, as discussed with Michal Privoznik privately.
Note compare with https://bugzilla.redhat.com/show_bug.cgi?id=1156194 which suggests using the GA to sync on a resume from suspend.
Marcelo, I think we should postpone resolving this bug untile bug 1156194 is fixed. I mean, until we have clear design from where the guest time sync command should be triggered.
(In reply to Michal Privoznik from comment #3) > Marcelo, I think we should postpone resolving this bug untile bug 1156194 is > fixed. I mean, until we have clear design from where the guest time sync > command should be triggered. Michal, some agent which is aware of migration (either libvirt or management software or qemu itself) must do this. This is necessary. The options are: 1) To sync from libvirt. Due to error reporting, not an option for libvirt: Option-1-libvirt: Do not introduce new function, sync time as part of LibvirtMigrate(). Outcome: Can't handle errors. 2) To sync from QEMU: same problems as above, no error reporting. Could query error separately as suggested in BZ1156194. 3) To sync from management software (on top of libvirt). The only option left. Michal, what is unclear?
(In reply to Marcelo Tosatti from comment #4) > (In reply to Michal Privoznik from comment #3) > > Marcelo, I think we should postpone resolving this bug untile bug 1156194 is > > fixed. I mean, until we have clear design from where the guest time sync > > command should be triggered. > > Michal, some agent which is aware of migration (either libvirt or management > software or qemu itself) must do this. This is necessary. > > The options are: > > 1) To sync from libvirt. Due to error reporting, not an option for libvirt: > Option-1-libvirt: Do not introduce new function, sync time as part of > LibvirtMigrate(). > Outcome: Can't handle errors. > > 2) To sync from QEMU: same problems as above, no error reporting. > Could query error separately as suggested in BZ1156194. > > 3) To sync from management software (on top of libvirt). > The only option left. > > Michal, what is unclear? Well, what's unclear is that you requested libvirt to issue time sync command on domain resume in the bug I am linking. But from libvirt POV, domain resume is part of migration. So I'd postpone resolving this bug until we have a clear design whether or not time sync should be issued automatically by libvirt. At the same time, I'm inclined to option #3 (which means handing over this bug to upper layer).
(In reply to Michal Privoznik from comment #5) > (In reply to Marcelo Tosatti from comment #4) > > (In reply to Michal Privoznik from comment #3) > > > Marcelo, I think we should postpone resolving this bug untile bug 1156194 is > > > fixed. I mean, until we have clear design from where the guest time sync > > > command should be triggered. > > > > Michal, some agent which is aware of migration (either libvirt or management > > software or qemu itself) must do this. This is necessary. > > > > The options are: > > > > 1) To sync from libvirt. Due to error reporting, not an option for libvirt: > > Option-1-libvirt: Do not introduce new function, sync time as part of > > LibvirtMigrate(). > > Outcome: Can't handle errors. > > > > 2) To sync from QEMU: same problems as above, no error reporting. > > Could query error separately as suggested in BZ1156194. > > > > 3) To sync from management software (on top of libvirt). > > The only option left. > > > > Michal, what is unclear? > > Well, what's unclear is that you requested libvirt to issue time sync > command on domain resume in the bug I am linking. But from libvirt POV, > domain resume is part of migration. So I'd postpone resolving this bug until > we have a clear design whether or not time sync should be issued > automatically by libvirt. At the same time, I'm inclined to option #3 (which > means handing over this bug to upper layer). Michal, Can you please assign the bug to RHEV-M, then? Is it necessary to open an OpenStack bug as well? TIA.
Done.(In reply to Marcelo Tosatti from comment #6) > Michal, > > Can you please assign the bug to RHEV-M, then? Done. > > Is it necessary to open an OpenStack bug as well? Yes. Done. Bug 1275338. > > TIA.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
we're tracking it in bug 1156194 already, no need to keep this one around anymore *** This bug has been marked as a duplicate of bug 1156194 ***