----- Original Message -----
From: "Mohsen Saeedi" <mohsen.saeedi(a)gmail.com>
To: "Oved Ourfalli" <ovedo(a)redhat.com>
Cc: users(a)ovirt.org
Sent: Tuesday, June 5, 2012 4:42:09 PM
Subject: Re: [Users] Ovirt - double use of PCI Address
/*Oved Ourfalli <ovedo(a)redhat.com>*/ wrote on Tue, 05 Jun 2012
09:29:19
-0400 (EDT):
>
> ----- Original Message -----
>> From: "Mohsen Saeedi"<mohsen.saeedi(a)gmail.com>
>> To: users(a)ovirt.org
>> Sent: Tuesday, June 5, 2012 4:24:46 PM
>> Subject: [Users] Ovirt - double use of PCI Address
>>
>>
>>
>>
>>
>> Hi
>>
>> I setup ovirt and some other things. I make a virtual machine
>> (CentOS
>> 6.2). installed and configured it. then power off it and make a
>> snapshot and create clone image from it.
>>
>> when i trying to start new machine, i got this error:
>>
>> 2012-06-05 13:16:15.433+0000: 2375: error :
>> qemuCollectPCIAddress:743
>> : XML error: Attempted double use of PCI Address '0:0:2.0'
>>
>> I remove the new machine and try to start old machine. i get the
>> error again! and i'm enable to start old machine.
>>
> Can you please attach the engine.log and vdsm.log files?
Yes, I attached both of them.
> Are you working with the most updated upstream code?
I'm working with build from git -
faef6297b0d01203e88040b2707f9abfbd754d3f. more information is
available
here:
http://www.dreyou.org/ovirt/
You can see the issue in vdsm.log file. You have 3 video cards, all on the same address.
<video>
<address domain="0x0000" function="0x0" slot="0x02"
type="pci" bus="0x00"/>
<model heads="1" type="qxl" vram="65536"/>
</video>
<video>
<address domain="0x0000" function="0x0" slot="0x02"
type="pci" bus="0x00"/>
<model heads="1" type="qxl" vram="65536"/>
</video>
<video>
<address domain="0x0000" function="0x0" slot="0x02"
type="pci" bus="0x00"/>
<model heads="1" type="qxl" vram="65536"/>
</video>
Looking at the vdsm code (in vdsm/libvirtvm.py), you can see why such a thing might happen
(also look at the FIXME comment :-) ).
# FIXME. We have an identification problem here.
# Video card device has not unique identifier, except the alias
# (but backend not aware to device's aliases).
# So, for now we can only assign the address according to devices order.
for vc in self._devices[vm.VIDEO_DEVICES]:
if not hasattr(vc, 'address') or not hasattr(vc,
'alias'):
vc.alias = alias
vc.address = address
break
# Update vm's conf with address
for dev in self.conf['devices']:
if (dev['type'] == vm.VIDEO_DEVICES) and \
(not dev.get('address') or not dev.get('alias')):
dev['address'] = address
dev['alias'] = alias
break
The code above is responsible to return the engine core the device addresses, after
libvirt executes the VM, so that they will be persistent, and used in future executions of
the VM.
Now, the engine core is aware of the alias (as of the exact commit you used :-) ), but the
first time you run the VM, you can get the addresses wrong, as the alias isn't taken
into account.
Would you like to try to fix this issue? The fix will be to make a better logic in the
code above. Similar examples can be found in this file, for example in the section that
does the same for controllers.
If not, let me know and I'll go ahead and fix that.
In the meantime, you can workaround this issue by going to the vm_device table,
identifying these three devices, leave the address as is for the first video card of your
VM (you probably have video0/1/2 as aliases), and try to run the VM again.
Now, the engine will pass the one with the correct address as the first, and libvirt will
allocate the right addresses to the other two.
Hopefully this will be enough.
Oved
>
> We had an issue with the monitors, in which the order of the
> monitor devices is important, as the first one needs to get the
> address 0:0:2.0, but that issue was fixed.
> Are you using more than one monitor?
No, I'm using spice or vnc just for getting graphic.
>
> The vdsm.log fill will help a lot here, as it contains the VM's
> domain XML file, which will show us all the devices we send
> libvirt, and all the addresses that the engine expects to get from
> it.
>
>
>>
>>
>> Any idea?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/users
>>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users