Avoid failing on XVA import if the interface doesn't exists

[olivierlambert]

Context

When you create an XVA to be distributed in the wild, the bridge value is saved in the XML inside the XVA. However, on destination, when importing the XVA, if the bridge doesn't exist, the entire import fails. For example, exporting with <name>bridge</name><value>xapi1</value> will trigger "INVALID_VALUE" about the bridge and will fail the import.

Solution

XVA import should avoid failing for this reason, and assign it to to an available bridge, like xapi0 or anything.

[psafont]

While this doesn't solve already-exported VMs, it's possible to create the XVAs without the device, and add the devices to them after importing, and finally starting the VMs. This exporting is done with the parameter excluded_device_types=vif, it also accepts a list to exclude more than one device type: vif,vbd,vgpu,vtpm

See the PR that added this functionality for more details: #5544

Now that I think about this, it looks like we're missing documentation about it

[olivierlambert]

That's a workaround to deal with the export process, but if there's more and more users/companies using XVAs, they will hit a wall. IMHO, a good solution is not to block the import if the bridge is unknown (or even maybe do not try to create any VIF, I'm fine with it). This makes the import a lot safer regardless what config you have.

edit: also, generating an XVA without VIF is indeed possible, it makes the initial configuration more complex, as you need to add a VIF after import, while maybe it will work out of the box on the default management interface if you keep the VIF all along.

[ydirson]

There is a workaround on import, as XAPI not only tries to select a Network using its bridge attribute, but also using its name_label. So for a one-shot import one can temporarily rename a network to the name exported into the XVA.

But a way to map the XVA contents into available networks would be a much cleaner solution.

[ydirson]

Also it would be nice if xe vm-import could report the network's name-label it's trying to find, that would make it much more practical to apply the above workaround