** Description changed: + [ Impact ] + + * The assumption is that everyone thought that "ConditionVirtualization=vmware" + is enough to make this a no-op on all non vmware environments. + + * But ordering dependencies like After/Before are evaluated first when building + the acyclic graph. + + * Only later comes the effect of ConditionVirtualization + + * But at this point it already implied that appamor (vmware needs this so + it is after) has been strictly ordered before cloud-init-local (does not need + apparmor, but in a vmware env should come after open-vm-tools) + + * Now apparmor is intializing not the fastest, and cloud-init-local is + in the critical path. Thereby, while open-vm-tools is not doing or providing + anything on non-vmware environments, it does slow down the critical chain by + the time apparmor.service needs to complete. And recent extensions to confine + more made this even more impactful in later releases. + + * The fix is to check for the virtualization type at generator timeframe, and + only insert the dependency when applicable. + One could argue that the generator could control even more, but e.g. keeping + "ConditionVirtualization=vmware" in the services instead is a good defense + in depth against unexpected effects. This makes the change minimal, we drop + the static dependencies from the service files and dynamically add it back + when running on vmware. Not more, not less. + + [ Test Plan ] + + * Boot on VMware and non VMware environments and check if the boot + is degraded in any way + + * For the speed boost we expect Alexander has a set to build images with + proposed solutions and running them, that was seen on the discussions and + should be executed again. It is essentially booting these on different + systems and comparing boot behavior and performance + + [ Where problems could occur ] + + * Startup behavior is the area to look out for. Either on VMware where + it should still be after apparmor (but if there is a mistake would not be) + or on other platforms if the intended change back-fires to be slower or + accidentally running vmware code that isn't needed. + In particular cloud-init-local now becomes able to run earlier, which is + great but if they actually had some dependency, never expressed and now + hit something - that could be an issue as well - so watching out how that + service works is important too. + The change was tested and reviewed with multiple POVs, it should be safe + but the above are the areas one would look for. + + [ Other Info ] + + * Thanks for the awesome initial analysis by Alexander Litvinov, the packagers + contribution here is only the idea how to then fix this - but without that + data we'd never had the chance to do so! + + --- --- + The open-vm-tools.service unit declares After=apparmor.service and Before=cloud-init-local.service with ConditionVirtualization=vmware. On non-VMware platforms (Azure, GCP, AWS), the condition correctly prevents the service from running, but systemd's static dependency graph still enforces the ordering constraints during boot, serializing cloud-init- local after AppArmor completes. Impact: ~2.5s boot delay on non-VMware platforms (tested on Azure Standard_D2as_v5) Scope: All non-VMware deployments (Azure, GCP, AWS, bare metal without VMware hypervisor) Evidence: Same-VM A/B test on Ubuntu 26.04 Server with single variable (open-vm-tools.service masked) shows AppArmor→cloud-init-local ordering flips from serialized (+0.011s) to overlapped (−1.24s) Root Cause: Systemd constructs the dependency graph before evaluating unit conditions at runtime. The After= and Before= directives are baked into the graph, so even though ConditionVirtualization=vmware correctly skips the service, the ordering constraint remains active. This forces cloud-init-local to wait for AppArmor to finish.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166910 Title: open-vm-tools.service unnecessary ordering constraint blocks cloud- init on non-VMware platforms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/2166910/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
