feature suggestion: migration network

[Dan Kenigsberg]

On Thu, Feb 14, 2013 at 01:43:55AM +0200, Moti Asayag wrote:
> On 02/10/2013 11:49 AM, Igor Lvovsky wrote:
> >    Hi,
> > I would like to summarize migration network discussion.
> > Please refer to wiki page http://www.ovirt.org/Features/Migration_Network
> > for more details
> > 
> 
> 1. Could you explain the motivation of not setting the migration role
> when migration is running ?
> "The "migration" role can be granted or taken on-the-fly, when hosts are
> active, as long as there are no currently-migrating VMs. "

The intention was to avoid an incoherence between currently-migrating
VMs, which are using the old migration network, and the newly-defined
network. People should be aware that you cannot change the effective
migration network of a VM while it is migrating.

However, this idea has the drawback of starvation: withing a big cluster
with many VMs, one VM is bound to be running when you want to change the
migration network.

Thus I'm inclined to drop this requirement. However we should make it
clear that any change to migration network affects only future
migrations.

> 2. dstqemu - should the engine send the migration network ip or the
> migration network name and let vdsm resolves the address ?

According to the suggested API, Engine sends the ip address of the
migration network on destination host. The recipient of the verb (source
vdsm) would have harder time figuring it out.

> 
> 3. Error handling: regarding the unpleasant surprise of an attempt to
> migrate a VM to a host which doesn't have the migration network - any
> new error should be received from vdsm for that ?

Vdsm would find out the problem asynchronously. Does engine poll
getMigrationStatus on the source host when migration fails? If it does
we could invent a new error code for that.

> 
> 4. Could we get to a point in which we don't have a network with a
> migration role ? We can rely on the management network, but what if
> network 'red' was selected to be a migration network and now it is being
> deleted? As i see it there are 3 options:
> 1. We block the operation and ask to select other migration network.
> 2. We automatically define the management network as the migration network.
> 3. We do nothing. On VM migration we'll analyse  the migration network
> (dynamically select the default network).

I prefer (3), to fall back to the management network as late as
possible. Frankly, I think that it would be nice to fall back to the old
API, of not sending dstqemu at all - we should have this logic anyway
for old cluster levels.

If someone recreate "red", we avoid the needless jitter suggested by (2).

Dan.