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

[Lee Garrett]

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.

> 
> 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