Lag in vCenter awareness of prior actions, aka vCenter migration can't find the network I just created

This is a somewhat oddball question. I'm trying to get a solid, precise understanding of how vCenter updates its "state model" with regard to programmatic changes to resources.

Here's our scenario:

(vCenter and ESXi hosts are latest 5.5 updates)

Using pyVmomi, we program against the infrastructure API, specifically connecting to vCenter.

In preparation for a VM migration, we create a portgroup on a target host (again, our connection is to vCenter, not the ESXi host.) The call returns successfully without error. I can validate the called succeeds via the ESXi logs.

We then immediately start a migration to the host.

*most* of the time, this works as expected. However, on occasion the migration fails because vCenter seems to not know about the portgroup we just created.

Typical message: "Currently connected network interface 'Network adapter 1' uses network 'nic-404316-430472-0', which is not accessible."

Well, we just created the network/portgroup a few milliseconds prior. I see success in the logs.

If I had to guess, I'd guess that vCenter forwards the portgroup creation off to the target ESXi hosts, but doesn't update its internal model of the world till some time later.

So my questions are:

1) How does vCenter's state model work?

2) What is the suggested way to know when it's safe to use a resource (e.g. a portgroup) after it's been created?



Tags (1)
0 Kudos
1 Reply

As further evidence that vCenter doesn't maintain an up-to-date state model, if the migration fails, I can simply retry just the migrate task, and it will eventually succeeds.

Further evidence that we've set up the migration properly, and the vCenter's state is simply lagging behind.

0 Kudos