On 05/05/2014 07:52 AM, Paolo Bonzini wrote:
> Il 04/05/2014 15:56, Alexey Kardashevskiy ha scritto:
>> On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
>>> This initial problem came form libvirt - it does not preserve
>>> the device order when running QEMU. So it is easy to get source QEMU with
Il 04/05/2014 15:56, Alexey Kardashevskiy ha scritto:
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
This initial problem came form libvirt - it does not preserve
the device order when running QEMU. So it is easy to get source QEMU with:
-device spapr-vscsi,id=scsi1,reg=0x2000 -device spapr
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
> This initial problem came form libvirt - it does not preserve
> the device order when running QEMU. So it is easy to get source QEMU with:
> -device spapr-vscsi,id=scsi1,reg=0x2000 -device
> spapr-vscsi,id=scsi0,reg=0x3000
> and destination QEM
On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote:
> This initial problem came form libvirt - it does not preserve
> the device order when running QEMU. So it is easy to get source QEMU with:
> -device spapr-vscsi,id=scsi1,reg=0x2000 -device
> spapr-vscsi,id=scsi0,reg=0x3000
> and destination QEM
Am 14.03.2014 05:18, schrieb Alexey Kardashevskiy:
> This initial problem came form libvirt - it does not preserve
> the device order when running QEMU. So it is easy to get source QEMU with:
> -device spapr-vscsi,id=scsi1,reg=0x2000 -device
> spapr-vscsi,id=scsi0,reg=0x3000
> and destination QEMU
This initial problem came form libvirt - it does not preserve
the device order when running QEMU. So it is easy to get source QEMU with:
-device spapr-vscsi,id=scsi1,reg=0x2000 -device spapr-vscsi,id=scsi0,reg=0x3000
and destination QEMU with:
-device spapr-vscsi,id=scsi0,reg=0x3000 -device spapr-v
