> still if adding hwclock command back has no conflict, it will be great helpful for customers.
Unfortunately hwclock is in universe so we cannot easily ship it automatically any more. We'd have to promote it back to main first. So it isn't so easy.
If you wish to undertake "Guest Customization" reliably then you must interact correctly with the interfaces provided by the guest OS. These will of course change from release to release of the guest OS, so in general it is always necessary to adapt interactions as required by new guest OS releases. Therefore your customers should not expect any new guest OS release to function correctly with your Guest Customization feature prior to receiving such an update from you.
Unfortunately it is not practical for us to provide backwards compatibility such as this in the general case. We might be able to make an exception but in this particular case this also seems impractical.
It sounds like this problem will go away as soon as you release your fixed vSphere update?
> still if adding hwclock command back has no conflict, it will be great helpful for customers.
Unfortunately hwclock is in universe so we cannot easily ship it automatically any more. We'd have to promote it back to main first. So it isn't so easy.
If you wish to undertake "Guest Customization" reliably then you must interact correctly with the interfaces provided by the guest OS. These will of course change from release to release of the guest OS, so in general it is always necessary to adapt interactions as required by new guest OS releases. Therefore your customers should not expect any new guest OS release to function correctly with your Guest Customization feature prior to receiving such an update from you.
Unfortunately it is not practical for us to provide backwards compatibility such as this in the general case. We might be able to make an exception but in this particular case this also seems impractical.
It sounds like this problem will go away as soon as you release your fixed vSphere update?