Trabajando en mi Workstation tuve la oportunidad de ver un caso de time drift extremo en un guest Windows virtualizado con KVM. Imperdible el video!



En 3 años trabajando con KVM es la primera vez que tengo un problema semejante. La situación es la siguiente:

  • Workstation de uso personal y host de máquinas virtuales KVM con CentOS 6.3
  • Procesador Intel(R) Core(TM) i3-2100 y 4 GB de memoria RAM
  • 3 máquinas virtuales KVM:
    • Windows XP con 2 núcleos asignados y 1GB de memoria RAM
    • Mageia 2 con 1 núcleo asignado y 512 MB de memoria RAM
    • Slacko Puppy con 1 núcleo asignado y 256 MB de memoria RAM (live cd)
  • Aplicaciones en ejecución con alto consumo de memoria y CPU:
    • Chrome
    • Compiz-fusion, Emerald

Las máquinas virtuales tenían un uptime de más de un mes, por descuido no las apagué (debía hacerlo ya que no las estaba usando) y estaban configuradas para iniciar automáticamente al iniciar el host. Como el hardware es relativamente importante nunca percibí una merma en el rendimiento (gracias también a la eficiencia de uso de recursos de KVM). Hoy necesitaba hacer unas pruebas en Windows XP y me dí cuenta que las tres VMs estaban prendidas, entonces en lugar de apagarlas puse a actualizar el guest Mageia mientras instalaba una feature de Windows en el guest Windows XP. Creo que no fue una buena idea, porque cuando terminó la instalación noté que había algo "raro" en el guest Windows.

La prueba está en el video, debe notarse la diferencia del reloj del guest Windows con el reloj del host (arriba a la derecha).

Este problema se denomina "time drift" y ocurre cuando el reloj de hardware de la máquina virtual se desfasa a un ritmo constante. Todas las tecnologías de virtualización actuales sufren este problema y tratan de compensarlo con diferentes técnicas.

Según este documento de knowlegdebase de Novell se produce una situación de time drift cuando las máquinas virtuales están mucho tiempo disponibles (idle). Aparentemente es lo que ocurrió en mi caso, ya que las máquinas virtuales estuvieron idle por mucho tiempo, y además pausadas cada vez que se apagaba el host (una vez por día). En general sucede que los relojes se atrasan porque se pierden interrupciones, en cambio en este caso el reloj se adelantaba a un ritmo impresionante. Seguiré investigando el tema para tratar de determinar por qué semejante ritmo de tics de reloj. Si alguien puede echar algo de luz sobre el asunto se agradece.

De todas formas voy a tratar de reproducir este fenómeno, con suerte se puede llegar a presentar nuevamente para intentar resolverlo, mientras tanto dejo información de ayuda al respecto obtenida de la documentación oficial de qemu, KVM y Red Hat.

Update

El problema se debe a la forma en que se actualiza el reloj al reanudar la máquina virtual luego de un largo período en pausa según la política utilizada en el timer RTC (tickpolicy). Se puede evitar cambiando la configuración de la máquina virtual. Leer el siguiente artículo: KVM - Time drift extremo en Windows XP (segunda parte).



Virtualization Administration Guide:

tickpolicy
The policy used to pass ticks on to the guest.
Table 9.4. tickpolicy attribute values
ValueDescription
none Continue to deliver at normal rate (i.e. ticks are delayed).
catchup Deliver at a higher rate to catch up.
merge Ticks merged into one single tick.
discard All missed ticks are discarded.



QEMU Emulator User Documentation:

-rtc [base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew]

Specify ‘base’ as utc or localtime to let the RTC start at the current UTC or local time, respectively. localtime is required for correct date in MS-DOS or Windows. To start at a specific point in time, providedate in the format 2006-06-17T16:01:21 or 2006-06-17. The default base is UTC.

By default the RTC is driven by the host system time. This allows to use the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP. If you want to isolate the guest time from the host, even prevent it from progressing during suspension, you can set ‘clock’ to vm instead.

Enable ‘driftfix’ (i386 targets only) if you experience time drift problems, specifically with Windows’ ACPI HAL. This option will try to figure out how many timer interrupts were not processed by the Windows guest and will re-inject them.



linux-kvm.org:

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.



Red Hat Enterprise Linux:

Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows uses the both the Real-Time Clock (RTC) and the Time Stamp Counter (TSC). For Windows guests the Real-Time Clock can be used instead of the TSC for all time sources which resolves guest timing issues.
To enable the Real-Time Clock for the PMTIMER clock source (the PMTIMER usually uses the TSC), add the following option to the Windows boot settings. Windows boot settings are stored in the boot.ini file. Add the following option to the end of the Windows boot line in the boot.ini file:
/usepmtimer
For more information on Windows boot settings and the usepmtimer option, refer to Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files.



Tal vez pueda interesarte


Compartí este artículo