From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mmr8e-0002U3-3b for qemu-devel@nongnu.org; Sun, 13 Sep 2009 11:37:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mmr8Z-0002Py-JC for qemu-devel@nongnu.org; Sun, 13 Sep 2009 11:37:15 -0400 Received: from [199.232.76.173] (port=55364 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mmr8Z-0002Pt-9e for qemu-devel@nongnu.org; Sun, 13 Sep 2009 11:37:11 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:42171) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mmr8Y-0005WG-F9 for qemu-devel@nongnu.org; Sun, 13 Sep 2009 11:37:11 -0400 Message-ID: <4AAD119F.2000107@web.de> Date: Sun, 13 Sep 2009 17:37:03 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090909222333.GA19385@shareable.org> <4AAA1059.9060505@siemens.com> <4AAD0B09.8040903@redhat.com> In-Reply-To: <4AAD0B09.8040903@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20EEB5DEB7CF1CC6D9384D0F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Blue Swirl , Anthony Liguori , Glauber Costa , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20EEB5DEB7CF1CC6D9384D0F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dor Laor wrote: > On 09/11/2009 11:54 AM, Jan Kiszka wrote: >> Jamie Lokier wrote: >>> Anthony Liguori wrote: >>>>> Besides the interface thing, I'm also interesting in comments on th= e >>>>> other core idea, the selectable RTC base clock. Do we want this >>>>> knob? Do >>>>> we want host_clock unconditionally? Or should the other RTC that >>>>> currently use the host time already also gain vm_clock support over= >>>>> the >>>>> time? >>>>> >>>> Hard to say. Doesn't the rtc keep track of wallclock time even on >>>> power >>>> off? I think using host_clock unconditionally does actually make >>>> sense. >>> >>> Sometimes it's useful to offset the emulated clock for one reason or >>> another, hence the -startdate options. But having it run at the >>> correct speed is usually useful :-) >> >> Indeed. >> >>> >>> Also, sometimes (due to licenses with wallclock limits) it's useful >>> for a guest to not see much time pass when the guest is powered off, >>> although it still needs to be positive. >> >> I'm not sure if this is a common use case. And it currently only seems= >> to be support by very few RTCs, the MC146818 being the most prominent >> one. >> >> I'm now a fan of converting the latter to the common scheme of using t= he >> host's system time (here via host_clock) and watch out for the need of= >> adding -rtc clock=3Dvm. >=20 > I'm in favor of sticking to clock=3Dvm as a default. > Most chances that the guest will have internet connect and the host (al= a > rom hypervisor) won't have. > Furthermore, if the guest and the host are running ntp it might cause > spurious ntp updates by the guest. Also on migration, you need to make > sure that both src and dst are synchronized. When using clock=3Dvm ther= e > is no such need. clock=3Dvm means that the RTC has no use as a reliable clock source, you always need additional help by NTP etc. in the guest -- unless you don't care about accurate time, of course. Note that, if you don't trust the virtual RTC (e.g. because it's driven by an isolated hypervisor) and you have NTP at hand, you typically configure the guest to update the RTC according to NTP. Then migration between two potentially unsynchronized hosts is also a none-issue. >=20 > Is the only case that clock=3Dhost is preferred is when the guest does = not > run ntp while the host does? It is currently a must-have if you want to synchronize host and guest clock (independent of the timezone) while NTP-like services are not an option. This includes the case where none of both have NTP access. Except for Jamie's case of extending some license runtime, I really see no real use for RTC based on vm_clock anymore. There is some reason why other RTCs are already based on the host clock. Jan --------------enig20EEB5DEB7CF1CC6D9384D0F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkqtEaMACgkQniDOoMHTA+n++gCeNCLMKXDs0YkAP965D439AKeU IxQAnAv6RZ8OHZMeTD7lH8yo+Mskv+sU =vwmN -----END PGP SIGNATURE----- --------------enig20EEB5DEB7CF1CC6D9384D0F--