You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During a migration, the current logic requires the target instance to be initialized with devices exactly matching the source. Those devices are then "rehydrated" with the migration payloads exported from the source, when that phase of the migration occurs. After discussions with @gjcolombo and others, one recurring conclusion was that it'd be nice if we could instantiate the devices directly from the migration payload.
Doing so would require some restructuring, particularly around what resources are required by each respective device when it is created. Viona, for example, requires the underlying vnic resource for initialization today. Moving it to a model similar to block devices, where it is attached to a "backend" resource prior to being pressed into service, might make sense.
An initialization pattern like this may help free us from demanding that the source and target VM instances adhere to similar internal structures when it comes to device naming, etc.
The text was updated successfully, but these errors were encountered:
During a migration, the current logic requires the target instance to be initialized with devices exactly matching the source. Those devices are then "rehydrated" with the migration payloads exported from the source, when that phase of the migration occurs. After discussions with @gjcolombo and others, one recurring conclusion was that it'd be nice if we could instantiate the devices directly from the migration payload.
Doing so would require some restructuring, particularly around what resources are required by each respective device when it is created. Viona, for example, requires the underlying vnic resource for initialization today. Moving it to a model similar to block devices, where it is attached to a "backend" resource prior to being pressed into service, might make sense.
An initialization pattern like this may help free us from demanding that the source and target VM instances adhere to similar internal structures when it comes to device naming, etc.
The text was updated successfully, but these errors were encountered: