-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VM always changed in eptRviMode,hvMode #472
Comments
Hi @cultpony - thank you for letting us know about this. This may be an instance of pulumi/pulumi-terraform-bridge#1785, and may have a generic fix for that in the future. |
I've also encountered a problem when trying to work around the issue; trying to ignore the properties causes an exception in the code somewhere, breaking the workflow entirely. |
Same problem here. But at least with the Python SDK and version 4.10.0 of the vSphere provider, setting Edit: After doing a
Before the refresh, running |
@guineveresaenger @t0yv0 Can we rollout PlanResourceChange to this resource to see if that helps? |
Perhaps we could add an env var to quickly try this without rebuilding. That could help to quickly figure it out if there's a repro at hand. |
@cultpony Could you please provide a larger self-sufficient repro without omitting most properties? That would help us troubleshoot the issue. Of course, replace any sensitive information. |
A new property has begun also exhibiting this problem: syncTimeWithHost I took the code I'm using and removed any outside references as much as possible, not interfering with any of the actual properties being set, you'll have to obviously spin up your own vsphere cluster and substitute the IDs involved. Removing "ignoreChanges: [ "syncTimeWithHost" ]" causes that to also always be changed. Ignoring changes on eptRviMode or hvMode causes the entire thing to break entirely (throws an exception). let metadata = Buffer.from(`# cloud-init\n`, "binary")
.toString("base64");
let userdata = Buffer.from(`#cloud-config\n`, "binary")
.toString("base64");
let template = await vsphere.getVirtualMachine({
name: "TEMPLATE_NAME",
datacenterId: "DC_ID",
});
new vsphere.VirtualMachine(`test-vm`, {
name: "test-vm",
clone: {
templateUuid: template.uuid,
},
extraConfig: {
"guestinfo.userdata": userdata,
"guestinfo.userdata.encoding": Encoding.Base64,
"guestinfo.metadata": metadata,
"guestinfo.metadata.encoding": Encoding.Base64,
},
networkInterfaces: [{
networkId: "NETWORK_ID",
adapterType: template.networkInterfaces[0].adapterType,
}],
disks: [{
label: template.disks[0].label,
size: template.disks[0].size,
unitNumber: 0,
datastoreId: "DATASTORE_ID",
},{
label: template.disks[1].label,
size: template.disks[1].size,
unitNumber: 1,
datastoreId: "DATASTORE_ID",
}],
numCpus: 4,
memory: 4096,
cpuReservation: 1000,
memoryReservation: 1024,
datastoreId: "DATASTORE_ID",
firmware: template.firmware,
resourcePoolId: "RESOURCE_POOL_ID",
folder: "/"
guestId: template.guestId,
waitForGuestIpTimeout: 10,
}, {
ignoreChanges: [ "syncTimeWithHost", ],
parent: parent,
}); |
Regarding the exceptions for |
per @mikhailshilkov 's suggestion, I've rolled an alpha release of the vsphere provider that includes the ability to add an environment variable that will allow the provider to use a new diffing strategy. Could you run your local program using
set in the environment, and let us know if this issue persists? Thank you so much! 🙏 |
Hi @guineveresaenger , thanks for providing an alpha release. Unfortunately, the behavior stays the same with the new version and the environment variable set. After doing a |
Thank you for trying out the alpha version, @nithom. We'll take another look as soon as we can. |
What happened?
I attempted to manage several VMs in a vSphere 8 installation via Pulumi, the VMs are created with cloud-init configuration and from a template, but eptRviMode and hvMode are not explicitly set at all.
Example
Output of "pulumi preview" after completing a "pulumi up"
Running "pulumi up" does not change this output but does cause the VMs to be shutdown, reconfigured and then started again.
Output of
pulumi about
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: