[pve-devel] virtiodisk ordering bug in current implementation + proposal for new qemu device syntax

Alexandre DERUMIER aderumier at odiso.com
Mon Aug 29 09:19:54 CEST 2011

can we defined a default config file with by exemple 5 disk and 5 nics devices-slot mapping

and if some advanced users want to have more disk, or more nics, they can just edit the file and add new mapping ?

so maxvirtiodisk and maxnic are just a count from this configfile ?

about libvirt, is a little different, in libvirt config xml, you defined all controllers with pci slot addres, and add disks on controller.

something like that

<balloon controlelr addr=0x1>
<audio controller addr=0x2>
<virtio controller 1  addr=0x3>
 <disk name="virtio1" .....>
<nic device1 addr=0x4>
<scsi controller 1 addr=0x5>
 <disk name⁼"scsi1"  ...>
 <disk name='scsi2" ...>

they are not predefined mapping.

so you can add the number disk or nic or other devices you want,and map them as you want, the only limit is the 31 pci slots.

----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Lundi 29 Août 2011 08:25:17 
Objet: RE: virtiodisk ordering bug in current implementation + proposal for new qemu device syntax 

> The question is, do you want to limit the virtio disk to X number, and nics to X 
> number ? 

No, I don't want to limit anything- I just do not guarantee a fixed pci address 
for vitrioN and netN where N >= 10 

So we simply assign fixed addr to virtio0-virtio9 and net0-net9. The rest of the devices 
does not get fixed pci addr (for now) 

> I don't if some proxmox users want 20 disk or 20 nics by example. 
> Also maybe we need to keep 1 or 2 slots for pci devices passthrough 

we can also limit fixed slot assignments to 6 or 8 devices, which is still 
enough for most use cases? 

> Personnaly, for my professional use, I never use more than 3 disk and 3 nics ;) 

Yes, so maybe 6 device with fixed pci addr are enough for now? 

> And yes, maybe is the future (6 months?) with pci bridge we can add more 
> devices. 


> So maybe a config file for all devices slots mapping can be the solution, so we 
> can extend it in the future. 

I suggest to simply hardcode that for now. 

sub get_pci_addr() { ... } 

We can make it configurable later. 

> Currently, i'm using this model config: (just an example) 
> pci: device=video0,bus=0,addr=2 
> pci: device=balloon,bus=0,addr=3 
> pci: device=audio0,bus=0,addr=4 
> pci: device=scsi0,bus=0,addr=5 
> pci: device=scsi1,bus=0,addr=6 

Those are the same mappings used by libvirt? I would like to have that compatible. 

> pci: device=virtio0,bus=0,addr=10 
> pci: device=virtio1,bus=0,addr=11 
> pci: device=virtio2,bus=0,addr=12 
> pci: device=virtio3,bus=0,addr=13 
> pci: device=virtio4,bus=0,addr=14 
> pci: device=virtio5,bus=0,addr=15 

look ok for me. 

> pci: device=virtio6,bus=0,addr=16 
> pci: device=virtio7,bus=0,addr=17 
> pci: device=virtio8,bus=0,addr=18 
> pci: device=virtio9,bus=0,addr=19 
> pci: device=virtio10,bus=0,addr=20 
> pci: device=net0,bus=0,addr=21 
> pci: device=net1,bus=0,addr=22 
> pci: device=net2,bus=0,addr=23 
> pci: device=net3,bus=0,addr=24 
> pci: device=net4,bus=0,addr=25 
> pci: device=net5,bus=0,addr=26 
> pci: device=net6,bus=0,addr=27 
> pci: device=net7,bus=0,addr=28 
> pci: device=net8,bus=0,addr=29 
> pci: device=net9,bus=0,addr=30 

maybe we do not need to assign all free addresses for now: 

pci: device=net0,bus=0,addr=20 
pci: device=net1,bus=0,addr=21 
pci: device=net2,bus=0,addr=22 
pci: device=net3,bus=0,addr=23 
pci: device=net4,bus=0,addr=24 
pci: device=net5,bus=0,addr=25 

I currently use 1d (29) for usb controllers (see pve-usb.cfg) 

- Dietmar 



	Alexandre Derumier 
Ingénieur système 
e-mail : aderumier at odiso.com 
Tél : +33 (0)3 20 68 88 90 
Fax : +33 (0)3 20 68 90 81 
45 Bvd du Général Leclerc 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aderumier.vcf
Type: text/x-vcard
Size: 183 bytes
Desc: not available
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20110829/d9b0ab88/attachment.vcf>

More information about the pve-devel mailing list