incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: Review Request: API commands to add or remove NIC from a VM
Date Wed, 30 Jan 2013 17:58:13 GMT

On 1/29/13 3:36 PM, "Marcus Sorensen" <> wrote:
>I've been reviewing this, and I'm still not sure that backing out the
>add nic db entry if the plug nic fails is the right way to go. We can
>catch the failure and remove it from the database, sure. But consider
>these scenarios:
>User runs deployVirtualMachine with parameter startvm=false.  We don't
>destroy their chosen VM config later when they launch the VM and a nic
>or something else fails to provision.

No, but we don't leave a VM running in an inconsistent state either.
Either all the nics are created or the vm fails to start

>User runs addNicToVirtualMachine when the VM is off. This essentially
>edits the Virtual Machine's config to the same as had the
>virtualmachine been deployed with the extra network. Again, if the
>plug fails when they turn the VM on, we don't destroy their config.

This should leave the VM not 'running'.

>All three of these, deployVirtualMachine, addNicToVirtualMachine when
>VM is on, and addNicToVirtualMachine when vm is off, rely on
>_networkMgr.createNicForVm to validate and apply for a nic. If we
>trust that to create a valid config for our VMs, then we shouldn't go
>back on that if there's a temporary problem.

The question is not of the config, but telling the end-user that the
addVmToNetwork failed but then leaving the nic entry in the db. An
automated orchestration tool using the API would list the VM, show it is
running and then see that there are N nics attached, without any idea that
some of the nics are in fact not attached.

>The whole goal of this feature was to be able to edit the VM's network
>config post-deploy. Doing it while the VM was running is a bonus, but
>not strictly necessary. Would it be better to go back to only allowing
>it while it's off (essentially the same thing, we won't know if the
>plug works until they attempt to start the VM, at which point we
>wouldn't remove it)? Or simply scrap this branch and move on to making
>nics their own entity?

I wouldn't scrap it. I am comfortable leaving it as is, or removing the
ability to hot plug.

View raw message