[Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot

[Lee Garrett]

On 21.09.23 19:43, Richard W.M. Jones wrote:
> On Thu, Sep 21, 2023 at 06:24:40PM +0200, Lee Garrett wrote:
>> On 21.09.23 18:08, Richard W.M. Jones wrote:
>>> On Thu, Sep 21, 2023 at 04:50:26PM +0200, Lee Garrett wrote:
>>>> After testing it again today, the guest agent is still not
>>>> installed, however this time the C:\Program
>>>> Files\Guestfs\Firstboot\log.txt exists:
>>>>
>>>> starting firstboot service
>>>> running "C:\Program Files\Guestfs\Firstboot\scripts\5000-0001-wait-pnp.bat"
>>>>          1 file(s) moved.
>>>> Wait for PnP to complete
>>>> .... exit code 0
>>>> running "C:\Program Files\Guestfs\Firstboot\scripts\5000-0002-install-qemu-ga-x86_64-msi-ps1.bat"
>>>>          1 file(s) moved.
>>>> Removing any previously scheduled qemu-ga installation
>>>> ERROR: The system cannot find the file specified.
>>>> Scheduling delayed installation of qemu-ga from qemu-ga-x86_64.msi
>>>> SUCCESS: The scheduled task "Firstboot-qemu-ga" has successfully been created.
>>>> .... exit code 0
>>>> running "C:\Program
>>>> Files\Guestfs\Firstboot\scripts\5000-0003-uninstall-VMware-Tools.bat"
>>>>          1 file(s) moved.
>>>> uninstalling VMware Tools
>>>> .... exit code 0
>>>> uninstalling firstboot service
>>>> Service uninstalled successfully
>>>>
>>>>
>>>> The folder scripts is empty, all scripts are in scripts-done. The
>>>> contents of the folder are:
>>>> 5000-0001-wait-pnp.bat
>>>> 123 5000-0001-wait-pnp.log
>>>> 5000-0002-install-qemu-ga-x86_64-msi-ps1.bat
>>>> 5000-0003-uninstall-VMware-Tools.bat
>>>> 5000-0003-uninstall-VMware-Tools.log
>>>>
>>>> Note that the .log is missing for qemu-ga.
>>>
>>> This is what we'd expect, except maybe the missing log for qemu-ga.
>>> It's a little odd that it is missing, but it's also possible that the
>>> log file doesn't get written if there's no output.
>>>
>>>> At least today I could twice provision the windows 11 VM, and in
>>>> both cases the main log.txt was generated by the time I checked. How
>>>> are the services scheduled? Could it be that they were delayed by >
>>>> 1h?
>>>
>>> Yes, we do actually try to delay qemu-ga installation.  It should only
>>> be delayed for about 120 seconds (not 1 hour).
>>>
>>> https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L580
>>>
>>> However there have been timezone bugs with this in the past (and maybe
>>> there still are), see the sordid history in these two links:
>>>
>>> https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L558
>>
>> I see. That's not reassuring. :(
>>
>>>
>>> Which TZ are you in?
>>
>> The host machine is UTC+2 (Berlin summer time), however the Windows
>> 11 trial vmware image itself defaults to UTC-8 (Pacific Time US &
>> Canada).
>>
>> After a little bit of digging this indeed seems to be the issue.
>>
>> `schtasks.exe /Query` gives:
>>
>> PS C:\Users\User> schtasks.exe /Query
>>
>> Folder: \
>> TaskName                                 Next Run Time          Status
>> ======================================== ====================== ===============
>> Firstboot-qemu-ga                        9/21/2023 4:04:00 PM   Ready
>> [...]
>>
>> which is ~7 hours in the future. Btw, running
>> `.\5000-0002-install-qemu-ga-x86_64-msi-ps1.bat` by hand works just
>> fine. So it definitely is just the scheduling issue that's
>> preventing it from running.
> 
> 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)


> 
> Rich.
> 
>>>
>>> Rich.
>>>
>>>> On 11.09.23 21:29, Richard W.M. Jones wrote:
>>>>>
>>>>> If we suspect that the whole firstboot mechanism might not be working
>>>>> with the new version of Windows, one way to test it (on this one, or a
>>>>> freshly installed Windows VM) would be:
>>>>>
>>>>>    $ virt-customize -a windows.img --firstboot-command 'echo hello'
>>>>>
>>>>> and see if "hello" is written in some form to the log.txt file inside
>>>>> the guest after it boots.
>>>>>
>>>>> If that doesn't work then it's likely some change in Windows which is
>>>>> breaking firstboot support.
>>>>>
>>>>> Rich.
>>>>>
>>>>
>>>> Regards, Lee
>>>
>>
>> Regards, Lee
>