Lee Garrett
2023-Sep-21 16:24 UTC
[Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot
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#L558I 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
Richard W.M. Jones
2023-Sep-21 17:43 UTC
[Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot
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. 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-- 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
Lee Garrett
2023-Sep-21 17:47 UTC
[Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot
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 >