Bug 1270302

Summary:	issue command to sync guest time upon migration
Product:	[oVirt] vdsm	Reporter:	Marcelo Tosatti <mtosatti>
Component:	General	Assignee:	Martin Polednik <mpoledni>
Status:	CLOSED DUPLICATE	QA Contact:	Aharon Canan <acanan>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bazulay, bugs, dgilbert, ecohen, gklein, jdenemar, lsurette, michal.skrivanek, mprivozn, rbalakri, tjelinek, ycui, yeylon, ylavi
Target Milestone:	ovirt-3.6.2	Flags:	ylavi: ovirt-3.6.z? ylavi: planning_ack+ rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1275338 (view as bug list)		Environment:
Last Closed:	2015-12-02 13:26:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1230126

Description Marcelo Tosatti 2015-10-09 14:26:44 UTC

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 17:04:28 UTC

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 11:28:27 UTC

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-14 01:20:16 UTC

(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 12:30:24 UTC

(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 19:56:05 UTC

(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 14:42:13 UTC

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-02 00:26:05 UTC

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 13:26:31 UTC

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 ***