Bug 1270302 - issue command to sync guest time upon migration
issue command to sync guest time upon migration
Status: CLOSED DUPLICATE of bug 1156194
Product: vdsm
Classification: oVirt
Component: General (Show other bugs)
---
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-3.6.2
: ---
Assigned To: Martin Polednik
Aharon Canan
virt
:
Depends On:
Blocks: 1230126
  Show dependency treegraph
 
Reported: 2015-10-09 10:26 EDT by Marcelo Tosatti
Modified: 2016-02-10 14:24 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1275338 (view as bug list)
Environment:
Last Closed: 2015-12-02 08:26:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑3.6.z?
ylavi: planning_ack+
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Marcelo Tosatti 2015-10-09 10:26:44 EDT
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.
Comment 2 Dr. David Alan Gilbert 2015-10-09 13:04:28 EDT
Note compare with https://bugzilla.redhat.com/show_bug.cgi?id=1156194
which suggests using the GA to sync on a resume from suspend.
Comment 3 Michal Privoznik 2015-10-12 07:28:27 EDT
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.
Comment 4 Marcelo Tosatti 2015-10-13 21:20:16 EDT
(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?
Comment 5 Michal Privoznik 2015-10-14 08:30:24 EDT
(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).
Comment 6 Marcelo Tosatti 2015-10-25 15:56:05 EDT
(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.
Comment 7 Michal Privoznik 2015-10-26 10:42:13 EDT
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.
Comment 8 Red Hat Bugzilla Rules Engine 2015-12-01 19:26:05 EST
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.
Comment 9 Michal Skrivanek 2015-12-02 08:26:31 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.