…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
1. the network interface has no «network» attribute (libvirtvm.py:936) 2. the network interface has no «macAddr» attribute (libvirtvm.py:2972)
So, we have an issue
1. either in vdsClient 2. or with the migration algo 3. or with NetworkInterfaceDevice class
Right now I'm tracing what's wrong there, but if you have any ideas, it will be nice.
On Mon, Feb 11, 2013 at 03:56:48PM +0100, Peter V. Saveliev wrote:
…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
- the network interface has no «network» attribute (libvirtvm.py:936)
- the network interface has no «macAddr» attribute (libvirtvm.py:2972)
So, we have an issue
- either in vdsClient
- or with the migration algo
- or with NetworkInterfaceDevice class
Right now I'm tracing what's wrong there, but if you have any ideas, it will be nice.
Are both source and target the same? Would you provide the complete traceback, as well as the whole migrationCreate command from the destination log?
Dan.
On 12 Feb 2013, at 09:53, Dan Kenigsberg danken@redhat.com wrote:
On Mon, Feb 11, 2013 at 03:56:48PM +0100, Peter V. Saveliev wrote:
…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
- the network interface has no «network» attribute (libvirtvm.py:936)
- the network interface has no «macAddr» attribute (libvirtvm.py:2972)
Did you provide them on cmdline? They're marked as mandatory but iirc not checked/enforced on VM creation using vdsClient
So, we have an issue
- either in vdsClient
- or with the migration algo
- or with NetworkInterfaceDevice class
Right now I'm tracing what's wrong there, but if you have any ideas, it will be nice.
Are both source and target the same? Would you provide the complete traceback, as well as the whole migrationCreate command from the destination log?
Dan.
12.02.2013 11:48, Michal Skrivanek kirjoitti:
On 12 Feb 2013, at 09:53, Dan Kenigsberg danken@redhat.com wrote:
On Mon, Feb 11, 2013 at 03:56:48PM +0100, Peter V. Saveliev wrote:
…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
- the network interface has no «network» attribute (libvirtvm.py:936)
- the network interface has no «macAddr» attribute (libvirtvm.py:2972)
Did you provide them on cmdline? They're marked as mandatory but iirc not checked/enforced on VM creation using vdsClient
<skip />
I do provide «macAddr», but do not provide «network»
On Feb 12, 2013, at 14:03 , Peter V. Saveliev peet@redhat.com wrote:
12.02.2013 11:48, Michal Skrivanek kirjoitti:
On 12 Feb 2013, at 09:53, Dan Kenigsberg danken@redhat.com wrote:
On Mon, Feb 11, 2013 at 03:56:48PM +0100, Peter V. Saveliev wrote:
…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
- the network interface has no «network» attribute (libvirtvm.py:936)
- the network interface has no «macAddr» attribute (libvirtvm.py:2972)
Did you provide them on cmdline? They're marked as mandatory but iirc not checked/enforced on VM creation using vdsClient
<skip />
I do provide «macAddr», but do not provide «network»
so can you try with network as well?
-- Peter V. Saveliev
12.02.2013 09:53, Dan Kenigsberg kirjoitti:
On Mon, Feb 11, 2013 at 03:56:48PM +0100, Peter V. Saveliev wrote:
…
system: RHEL 6.3 vdsm: ovirt master head
Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host:
- the network interface has no «network» attribute (libvirtvm.py:936)
- the network interface has no «macAddr» attribute (libvirtvm.py:2972)
So, we have an issue
- either in vdsClient
- or with the migration algo
- or with NetworkInterfaceDevice class
Right now I'm tracing what's wrong there, but if you have any ideas, it will be nice.
Are both source and target the same?
Yes.
Would you provide the complete traceback, as well as the whole
Thread-18::ERROR::2013-02-11 13:50:02,764::vm::715::vm.Vm::(_startUnderlyingVm) vmId=`4808bd18-b6f8-4c9f-b9c4-953543fd69d7`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 677, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1452, in _run **dev)) File "/usr/share/vdsm/libvirtvm.py", line 931, in __init__ self._customize() File "/usr/share/vdsm/libvirtvm.py", line 936, in _customize self.driver = vhosts.get(self.network, False) AttributeError: 'NetworkInterfaceDevice' object has no attribute 'network' Thread-18::DEBUG::2013-02-11 13:50:02,767::vm::1064::vm.Vm::(setDownStatus) vmId=`4808bd18-b6f8-4c9f-b9c4-953543fd69d7`::Changed state to Down: 'NetworkInterfaceDevice' object has no attribute 'network'
migrationCreate command from the destination log?
Dan.
vdsClient 0 create /dev/null vmId=`uuidgen` macAddr=00:11:22:33:44:55 memSize=256 display=vnc
On Tue, Feb 12, 2013 at 02:40:51PM +0100, Peter V. Saveliev wrote:
from the log also: see attachment
-- Peter V. Saveliev
Thread-15::DEBUG::2013-02-08 12:43:28,873::BindingXMLRPC::926::vds::(wrapper) client [10.34.63.165]::call vmMigrationCreate with ({'status': 'Up', 'username': 'Unknown', 'macAddr': '00:00:00:00:00:01', 'nicModel ': 'rtl8139,pv', 'afterMigrationStatus': 'Up', 'displayIp': '0', 'vmId': '593cc128-5c0b-495a-94e5-274c3f7ad5e1', 'vmName': 'n593cc128-5c0b-495a-94e5-274c3f7ad5e1', 'devices': [{'device': 'memballoon', 'specParam s': {'model': 'none'}, 'type': 'balloon'}, {'device': 'virtio-serial', 'alias': 'virtio-serial0', 'type': 'controller', 'address': {'slot': '0x05', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': ' 0x0'}}, {'device': 'cirrus', 'specParams': {'vram': '65536'}, 'address': {'slot': '0x02', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'type': 'video', 'alias': 'video0'}, {'nicModel': ' rtl8139', 'macAddr': '00:00:00:00:00:01', 'linkActive': True, 'network': 'rhevm', 'alias': 'net1', 'address': {'slot': '0x04', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bri dge', 'type': 'interface', 'name': 'vnet1'}, {'nicModel': 'virtio', 'macAddr': '00:00:00:00:00:01', 'linkActive': True, 'network': 'rhevm', 'alias': 'net1', 'address': {'slot': '0x04', 'bus': '0x00', 'domain': ' 0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface', 'name': 'vnet1'},
Somehow you have two interfaces defined, both with the same macAddr 00:00:00:00:00:01 and network rhevm. This does not help much in understanding the validation problem that you found in vdsm, but it may help you.
{'index': 2, 'iface': 'ide', 'name': 'hdc', 'format': 'raw', 'alias': 'ide0-1-0', 'readonly': 'True', 'trues ize': 0, 'address': {'bus': '1', 'controller': '0', 'type': 'drive', 'target': '0', 'unit': '0'}, 'device': 'cdrom', 'shared': False, 'path': '', 'propagateErrors': 'off', 'type': 'disk'}, {'device': 'usb', 'ali as': 'usb0', 'type': 'controller', 'address': {'slot': '0x01', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x2'}}, {'device': 'ide', 'alias': 'ide0', 'type': 'controller', 'address': {'slot': '0x01', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x1'}}, {'device': 'bridge', 'alias': 'net0', 'type': 'interface', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'p ci', 'function': '0x0'}}, {'device': 'unix', 'alias': 'channel0', 'type': 'channel', 'address': {'bus': '0', 'controller': '0', 'type': 'virtio-serial', 'port': '1'}}, {'device': 'unix', 'alias': 'channel1', 'ty pe': 'channel', 'address': {'bus': '0', 'controller': '0', 'type': 'virtio-serial', 'port': '2'}}], 'smp': '1', 'vmType': 'kvm', 'display': 'vnc', 'displaySecurePort': '-1', '_srcDomXML': "<domain type='kvm' id=
vdsm-devel@lists.stg.fedorahosted.org