On Fri, Sep 22, 2023 at 05:27:25PM +0200, Lee Garrett wrote: > On 22.09.23 16:47, Lee Garrett wrote: > >On 22.09.23 14:54, Richard W.M. Jones wrote: > >>On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote: > >>>On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote: > >>>>On 21.09.23 19:43, Richard W.M. Jones wrote: > >>>>>So this is probably another instance or variation of the timezone > >>>>>formatting problem (of schtasks). Which version of virt-v2v is this? > >>>>>I want to check that you have a version with all the latest patches in > >>>>>this area. > >>>> > >>>>It's 2.2.0-1 from Debian (12) bookworm. I've verified that it > >>>>doesn't have any distro-specific patches. > >>>> > >>>>(https://salsa.debian.org/libvirt-team/virt-v2v/-/tree/debian/master/debian > >>>>would have a patches/series file in this case) > >>> > >>>The timezone fixes are: > >>> > >>>commit 597d177567234c3a539098c423649781424eeb6f > >>>Author: Laszlo Ersek <ler...@redhat.com> > >>>Date: Tue Mar 8 15:30:51 2022 +0100 > >>> > >>> convert_windows: rewrite "configure_qemu_ga" script purely in > >>>PowerShell > >>> > >>>commit d9dc6c42ae64ba92993dbd9477f003ba73fcfa2f > >>>Author: Richard W.M. Jones <rjo...@redhat.com> > >>>Date: Fri Nov 12 08:47:55 2021 +0000 > >>> > >>> convert/convert_windows.ml: Handle date formats with dots instead of / > >>> > >>>They are all included in >= 2.0 > >>> > >>>I wonder if 597d177567 has a subtle flaw, or if we introduced a bug > >>>somewhere when refactoring this code later. > >>> > >>>Lee: Do you have a theory about exactly what is wrong with the > >>>schtasks date? Like what was it supposed to be, assuming it was 120 > >>>seconds in the future from boot time, versus what it was set to: > >>> > >>>>Firstboot-qemu-ga 9/21/2023 4:04:00 PM Ready > >>> > >>>Could a date or time field have not been swapped or been corrupted > >>>in some predictable way? > >> > >>Or in even simpler terms, what is the time (and timezone) that > >>this ^^^ machine was booted? > > > >I believe I have it figured out. > >The guest local time is currently 7:08 AM (a few minutes after > >firstboot/provisioning), pacific daylight time (UTC-7, though > >Windows displays it as "UTC-08:00"). This is the timezone that the > >guest comes configured with at first boot. The task is scheduled > >for 2:01 PM, meaning it's scheduled to run ~7 hours in the future. > > > >So it seems like the task was meant to be scheduled for 2:01 PM > >UTC (= 7:01 AM PDT), but for some reason was scheduled for 2:01 PM > >*local time*. > > > > From what I can see, the host machine time zone is irrelevant (UTC+2). > > > >I don't know where the timezone mixup comes from, though. Running > >`(get-date)` in the powershell at this point correctly returns the > >local time (7:08 AM). I guess during injection the time is in UTC, > >and schtasks.exe has no awareness of timezones? > > I digged a bit into the XML description and noticed this: > > <clock offset="utc"/> > > To my knowledge Windows runs the BIOS clock in local time. So This > should probably be > > <clock offset="localtime"> > <timer name="rtc" tickpolicy="catchup"/> > <timer name="pit" tickpolicy="delay"/> > <timer name="hpet" present="no"/> > <timer name="hypervclock" present="yes"/> > </clock> > > as this is what libvirt uses in the preset for Windows 11 hosts. I > manually changed this before first boot, however it didn't solve the > issue. It only increased the offset to +9 hours in the future (7 > hours difference to UTC, +2 hours of local timezone). How does the > firstboot injection exactly happen? Is the guest actually booted for > it?
No, the guest is not running. Rich. > > > >> > >>Rich. > >> > >>>The code we run is here: > >>> > >>>https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L571 > >>> > >>>Ming: this could be a bug affecting PST (UTC-8) guests, perhaps > >>>somehow related to having a single digit month field? > >>> > >>>Rich. > >>> > >>>-- > >>>Richard Jones, Virtualization Group, Red Hat > >>>http://people.redhat.com/~rjones > >>>Read my programming and virtualization blog: http://rwmj.wordpress.com > >>>libguestfs lets you edit virtual machines. Supports shell scripting, > >>>bindings from many languages. http://libguestfs.org > >> > > -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs