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

Reply via email to