Hide Forgot
Description of problem: Don't attempt to start VM if it's nic is configured for non-existent network. Can happen if one imports the VM that was exported from another setup. Version-Release number of selected component (if applicable): ovirt-engine-3.0.0_0001-1.3.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. in one setup, create a VM that has a NIC connected to "network1" network 2. export the VM, import it to another setup/DC/whatever where network "network1" is not present 3. try to run VM from Admin Portal Actual results: ovirt-engine tries to run the VM but it fails with message: VM <vm_name> is down. Exit message Failed to add tap interface to bridge 'network1': No such device. Expected results: ovirt-engine won't try to start the VM and frontend will pop up error dialog instead that selected network is not available Additional info: VDSM log: Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 518, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1169, in _run self._connection.createXML(domxml, flags), File "/usr/share/vdsm/libvirtconnection.py", line 79, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2100, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: Failed to add tap interface to bridge 'network1': No such device Thread-4388::DEBUG::2012-01-30 18:52:15,959::vm::882::vm.Vm::(setDownStatus) vmId=`17c39f1e-3c59-4ed1-b26c-341ed956d650`::Changed state to Down: Failed to add tap interface to bridge 'network1': No such device
BTW - The nic should be removed when importing a VM with a netwrok that is not defined in the setup an error should be issued to the log. Still we should block strting such a VM in case we have one in the setup.
(In reply to comment #1) > BTW - The nic should be removed when importing a VM with a netwrok that is > not defined in the setup an error should be issued to the log. > correction - an informative message should be issued to the audit log > Still we should block strting such a VM in case we have one in the setup.
We have three different cases when running a VM: 1. The VM has a network interface which is not a VM network - already have an error message today (Failed ${action} ${type} the network/s ${Networks} is/are not a VM network.) 2. The VM has a network interface on a network that doesn't exist in the cluster - will add an error message here (Failed ${action} ${type} the network/s ${Networks} don't exist in the cluster.) 3. The VM has a network interface with an empty network (AFAIU, this is supposed to be the new behaviour when importing a VM with interfaces on non-existing networks - will add an error message here (Failed ${action} ${type} one or more network interfaces are missing a network. Please configure the network for these interfaces and try again.)
Commit: 84784f08340f97f2023dbf69f778f466f31a8a6b http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=84784f08340f97f2023dbf69f778f466f31a8a6b Contains revised error messages as well.
closing ON_QA bugs as oVirt 3.1 was released: http://www.ovirt.org/get-ovirt/