Re: 8 nic limit
On 2011-09-03 13:54, Richard Weinberger wrote: > Hi! > > qemu-kvm seems to support only 8 network interfaces. > I found this posting from 2009: > http://www.mail-archive.com/kvm@vger.kernel.org/msg10104.html > > Why is MAX_NICS still only 8? > Please raise this limit in future releases. > > I have some use cases where much more than 8 nics are needed. > (Lot's of VLANs...) If you avoid the legacy -net and create networks via "-device " and -netdev, you won't face this limit. Jan signature.asc Description: OpenPGP digital signature
8 nic limit
Hi! qemu-kvm seems to support only 8 network interfaces. I found this posting from 2009: http://www.mail-archive.com/kvm@vger.kernel.org/msg10104.html Why is MAX_NICS still only 8? Please raise this limit in future releases. I have some use cases where much more than 8 nics are needed. (Lot's of VLANs...) Thanks, //richard P.s: Please CC me. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hitting 29 NIC limit
On 11/16/2010 11:23 AM, Michael S. Tsirkin wrote: On Thu, Oct 14, 2010 at 05:17:36PM -0500, Anthony Liguori wrote: On 10/14/2010 05:12 PM, Anjali Kulkarni wrote: Thanks. Does this work for e1000 as well? Haven't tried. I don't know how various e1000 drivers would react. Also, does it support pci hotplug? No, but that's fixable down the road. Regards, Anthony Liguori Probably not. FWIW, by fixable, I meant, we could add the ability to hot plug a multi-port NIC device. For instance, we could have -device virtio-net-pci-x8 which would be an 8-port virtio-net card. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 05:17:36PM -0500, Anthony Liguori wrote: > On 10/14/2010 05:12 PM, Anjali Kulkarni wrote: > >Thanks. Does this work for e1000 as well? > > Haven't tried. I don't know how various e1000 drivers would react. > > >Also, does it support pci hotplug? > > No, but that's fixable down the road. > > Regards, > > Anthony Liguori Probably not. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 02:07:17PM +0200, Avi Kivity wrote:
> On 10/14/2010 12:54 AM, Anthony Liguori wrote:
> >On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
> >>
> >>Hi,
> >>
> >>Using the legacy way of starting up NICs, I am hitting a
> >>limitation after 29
> >>NICs ie no more than 29 are detected (that's because of the 32 PCI slot
> >>limit on a single bus- 3 are already taken up)
> >>I had initially increased the MAX_NICS to 48, just on my tree, to get to
> >>more, but ofcource that wont work.
> >>Is there any way to go beyond 29 NICs the legacy way? What is
> >>the maximum
> >>that can be supported by the qdev mothod?
> >
> >I got up to 104 without trying very hard using the following script:
> >
> >args=""
> >for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
> >for fn in 0 1 2 3 4 5 6 7; do
> >args="$args -netdev user,id=eth${slot}_${fn}"
> >args="$args -device
> > virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
> >done
> >done
> >
> >x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
> >-enable-kvm
> >
> >The key is to make the virtio-net devices multifunction and to
> >fill out all 8 functions for each slot.
>
> This is unlikely to work right wrt pci hotplug. If we want to
> support a large number of interfaces, we need true multiport cards.
Bridge support seems to be working mostly fine here.
That will let you go up to 256 devices without multifunction.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit (+Intel VT-c)
On Thu, 14 Oct 2010 14:07 +0200, "Avi Kivity" wrote: > On 10/14/2010 12:54 AM, Anthony Liguori wrote: > > On 10/13/2010 05:32 PM, Anjali Kulkarni wrote: > What's the motivation for such a huge number of interfaces? Ultimately to bring multiple 10Gb bonds into a Vyatta guest. --- > BTW, I don't think it's possible to hot-add physical functions. I > believe I know of a card that supports dynamic add of physical functions > (pre-dating SR-IOV) I don't know what you're talking about, but it seems you have a better handle than I on this VT-c stuff, so perhaps misguidedly I'll direct my next question to you. Is additional configuration required to make use of SR-IOV & VTq? I don't immediateley understand how the queueing knows who is who in the absense of eth.vlan- or if I need to for that matter. My hope is that this is something like plug n play as long as kernel, host & driver versions are >foo, but I haven't yet found documentation to confirm it. For the sake of future queries, I've come across these references so far: http://download.intel.com/design/network/applnots/321211.pdf http://www.linux-kvm.org/wiki/images/6/6a/KvmForum2008%24kdf2008_7.pdf http://www.mail-archive.com/kvm@vger.kernel.org/msg27860.html http://www.mail-archive.com/kvm@vger.kernel.org/msg22721.html http://thread.gmane.org/gmane.linux.kernel.mm/38508 http://ark.intel.com/Product.aspx?id=36918 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 05:57 AM, Anthony Liguori wrote: > > I've always been sceptical of this. When physical systems have a large > number of NICs, it's via multiple functions, not a bunch of PCI bridges. > Actually a lot of multiport PCI cards are in fact single or dual NICs behind PCI bridges. -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
Anthony Liguori writes:
> On 10/14/2010 07:36 AM, Markus Armbruster wrote:
>> Avi Kivity writes:
>>
>>
>>> On 10/14/2010 12:54 AM, Anthony Liguori wrote:
>>>
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
> Hi,
>
> Using the legacy way of starting up NICs, I am hitting a limitation
> after 29
> NICs ie no more than 29 are detected (that's because of the 32 PCI slot
> limit on a single bus- 3 are already taken up)
> I had initially increased the MAX_NICS to 48, just on my tree, to get to
> more, but ofcource that wont work.
> Is there any way to go beyond 29 NICs the legacy way? What is the
> maximum
> that can be supported by the qdev mothod?
>
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill
out all 8 functions for each slot.
>> I'm amazed that works. Can't see how creating another qdev in the same
>> slot makes a proper multifunction device.
>>
>
> multifunction=on sets the multifunction bit for the PCI device. Then
> it's a matter of setting the address to be a specific function.
I missed that bit, or perhaps forgot it already. Neat!
Unfortunately, it's not yet good enough for hot plug. We need to plug
the complete device in one go, not function by function. This is harder
than hot unplug, where we can just add a command "unplug this PCI
device", then device_del its functions at our leisure. The symmetric
way to plug would be device_add the functions, then plug the device.
Backward compatibility headache: current device_add/del plug/unplug
automatically.
> Our default platform devices are actually multifunction.
Yes, but they're built "by hand".
[...]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 05:12 PM, Anjali Kulkarni wrote:
Thanks. Does this work for e1000 as well?
Haven't tried. I don't know how various e1000 drivers would react.
Also, does it support pci hotplug?
No, but that's fixable down the road.
Regards,
Anthony Liguori
Anjali
On 10/14/10 3:09 PM, "Anthony Liguori" wrote:
On 10/14/2010 05:00 PM, Anjali Kulkarni wrote:
Can you send me pointers to the qdev documentation? How can I use it? Will
it allow us to scale above the 32 PCI limit?
It's all below. You just have to create a PCI device and mark the
multifunction flag to on and then assign it a PCI address that includes
a function number. Then you can pack 8 virtio PCI devices into a single
slot.
Regards,
Anthony Liguori
Anjali
On 10/14/10 2:57 PM, "Anthony Liguori" wrote:
On 10/14/2010 04:42 PM, Richard W.M. Jones wrote:
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote:
Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
any type of device we emulate.
Break the 29/30/31 virtio-blk limit ... please!
It was broken ages ago:
anth...@howler:~$ wc -l /proc/partitions; tail /proc/partitions
422 /proc/partitions
251 1618 1 vdcx2
251 1621 489951 vdcx5
251 1632 10485760 vdcy
251 16339992398 vdcy1
251 1634 1 vdcy2
251 1637 489951 vdcy5
251 1648 10485760 vdcz
251 16499992398 vdcz1
251 1650 1 vdcz2
251 1653 489951 vdcz5
This is what makes qdev so useful.
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -drive
file=/home/anthony/images/linux.img,if=none,snapshot=on,id=disk${slot}_${fn}>>>
"
args="$args -device
virtio-blk-pci,addr=${slot}.${fn},drive=disk${slot}_${fn},multifunction=on"
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm -serial stdio
Regards,
Anthony Liguori
Rich.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
Thanks. Does this work for e1000 as well?
Also, does it support pci hotplug?
Anjali
On 10/14/10 3:09 PM, "Anthony Liguori" wrote:
> On 10/14/2010 05:00 PM, Anjali Kulkarni wrote:
>> Can you send me pointers to the qdev documentation? How can I use it? Will
>> it allow us to scale above the 32 PCI limit?
>>
>
> It's all below. You just have to create a PCI device and mark the
> multifunction flag to on and then assign it a PCI address that includes
> a function number. Then you can pack 8 virtio PCI devices into a single
> slot.
>
> Regards,
>
> Anthony Liguori
>
>> Anjali
>>
>>
>> On 10/14/10 2:57 PM, "Anthony Liguori" wrote:
>>
>>
>>> On 10/14/2010 04:42 PM, Richard W.M. Jones wrote:
>>>
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote:
> Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
> any type of device we emulate.
>
>
Break the 29/30/31 virtio-blk limit ... please!
>>> It was broken ages ago:
>>>
>>> anth...@howler:~$ wc -l /proc/partitions; tail /proc/partitions
>>> 422 /proc/partitions
>>>251 1618 1 vdcx2
>>>251 1621 489951 vdcx5
>>>251 1632 10485760 vdcy
>>>251 16339992398 vdcy1
>>>251 1634 1 vdcy2
>>>251 1637 489951 vdcy5
>>>251 1648 10485760 vdcz
>>>251 16499992398 vdcz1
>>>251 1650 1 vdcz2
>>>251 1653 489951 vdcz5
>>>
>>> This is what makes qdev so useful.
>>>
>>> args=""
>>> for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
>>> for fn in 0 1 2 3 4 5 6 7; do
>>> args="$args -drive
>>>
file=/home/anthony/images/linux.img,if=none,snapshot=on,id=disk${slot}_${fn}>>>
"
>>> args="$args -device
>>> virtio-blk-pci,addr=${slot}.${fn},drive=disk${slot}_${fn},multifunction=on"
>>> done
>>> done
>>>
>>> x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
>>> -enable-kvm -serial stdio
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>
Rich.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 05:00 PM, Anjali Kulkarni wrote:
Can you send me pointers to the qdev documentation? How can I use it? Will
it allow us to scale above the 32 PCI limit?
It's all below. You just have to create a PCI device and mark the
multifunction flag to on and then assign it a PCI address that includes
a function number. Then you can pack 8 virtio PCI devices into a single
slot.
Regards,
Anthony Liguori
Anjali
On 10/14/10 2:57 PM, "Anthony Liguori" wrote:
On 10/14/2010 04:42 PM, Richard W.M. Jones wrote:
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote:
Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
any type of device we emulate.
Break the 29/30/31 virtio-blk limit ... please!
It was broken ages ago:
anth...@howler:~$ wc -l /proc/partitions; tail /proc/partitions
422 /proc/partitions
251 1618 1 vdcx2
251 1621 489951 vdcx5
251 1632 10485760 vdcy
251 16339992398 vdcy1
251 1634 1 vdcy2
251 1637 489951 vdcy5
251 1648 10485760 vdcz
251 16499992398 vdcz1
251 1650 1 vdcz2
251 1653 489951 vdcz5
This is what makes qdev so useful.
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -drive
file=/home/anthony/images/linux.img,if=none,snapshot=on,id=disk${slot}_${fn}"
args="$args -device
virtio-blk-pci,addr=${slot}.${fn},drive=disk${slot}_${fn},multifunction=on"
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm -serial stdio
Regards,
Anthony Liguori
Rich.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 04:57:36PM -0500, Anthony Liguori wrote: > On 10/14/2010 04:42 PM, Richard W.M. Jones wrote: > >On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote: > >>Or a PCI bridge to wire up more PCI buses, so we raise the max limit for > >>any type of device we emulate. > >Break the 29/30/31 virtio-blk limit ... please! > > It was broken ages ago: [...] Excellent news indeeed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
Can you send me pointers to the qdev documentation? How can I use it? Will
it allow us to scale above the 32 PCI limit?
Anjali
On 10/14/10 2:57 PM, "Anthony Liguori" wrote:
> On 10/14/2010 04:42 PM, Richard W.M. Jones wrote:
>> On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote:
>>
>>> Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
>>> any type of device we emulate.
>>>
>> Break the 29/30/31 virtio-blk limit ... please!
>>
>
> It was broken ages ago:
>
> anth...@howler:~$ wc -l /proc/partitions; tail /proc/partitions
> 422 /proc/partitions
> 251 1618 1 vdcx2
> 251 1621 489951 vdcx5
> 251 1632 10485760 vdcy
> 251 16339992398 vdcy1
> 251 1634 1 vdcy2
> 251 1637 489951 vdcy5
> 251 1648 10485760 vdcz
> 251 16499992398 vdcz1
> 251 1650 1 vdcz2
> 251 1653 489951 vdcz5
>
> This is what makes qdev so useful.
>
> args=""
> for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
> for fn in 0 1 2 3 4 5 6 7; do
> args="$args -drive
> file=/home/anthony/images/linux.img,if=none,snapshot=on,id=disk${slot}_${fn}"
> args="$args -device
> virtio-blk-pci,addr=${slot}.${fn},drive=disk${slot}_${fn},multifunction=on"
> done
> done
>
> x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
> -enable-kvm -serial stdio
>
> Regards,
>
> Anthony Liguori
>
>> Rich.
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 04:42 PM, Richard W.M. Jones wrote:
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote:
Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
any type of device we emulate.
Break the 29/30/31 virtio-blk limit ... please!
It was broken ages ago:
anth...@howler:~$ wc -l /proc/partitions; tail /proc/partitions
422 /proc/partitions
251 1618 1 vdcx2
251 1621 489951 vdcx5
251 1632 10485760 vdcy
251 16339992398 vdcy1
251 1634 1 vdcy2
251 1637 489951 vdcy5
251 1648 10485760 vdcz
251 16499992398 vdcz1
251 1650 1 vdcz2
251 1653 489951 vdcz5
This is what makes qdev so useful.
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -drive
file=/home/anthony/images/linux.img,if=none,snapshot=on,id=disk${slot}_${fn}"
args="$args -device
virtio-blk-pci,addr=${slot}.${fn},drive=disk${slot}_${fn},multifunction=on"
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm -serial stdio
Regards,
Anthony Liguori
Rich.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 01:10:47PM +0100, Daniel P. Berrange wrote: > Or a PCI bridge to wire up more PCI buses, so we raise the max limit for > any type of device we emulate. Break the 29/30/31 virtio-blk limit ... please! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 04:11 PM, Anthony Liguori wrote: On 10/14/2010 08:23 AM, Avi Kivity wrote: On 10/14/2010 02:54 PM, Anthony Liguori wrote: The key is to make the virtio-net devices multifunction and to fill out all 8 functions for each slot. This is unlikely to work right wrt pci hotplug. Yes. Our hotplug design is based on devices.. This is wrong, it should be based on bus-level concepts (like PCI slots). If we want to support a large number of interfaces, we need true multiport cards. This magic here creates a multiport virtio-net card so I'm not really sure what you're suggesting. It would certainly be nice to make this all more user friendly (and make hotplug work). The big issue is to fix hotplug. Yes, but this is entirely independent of multifunction devices. Today we shoe-horn hot remove into device_del. Instead, we should have explicit bus-level interfaces for hot remove. I'm not saying multiplug is not the right way to approach this (it is). The only concern is to get hotplug right. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 08:23 AM, Avi Kivity wrote: On 10/14/2010 02:54 PM, Anthony Liguori wrote: The key is to make the virtio-net devices multifunction and to fill out all 8 functions for each slot. This is unlikely to work right wrt pci hotplug. Yes. Our hotplug design is based on devices.. This is wrong, it should be based on bus-level concepts (like PCI slots). If we want to support a large number of interfaces, we need true multiport cards. This magic here creates a multiport virtio-net card so I'm not really sure what you're suggesting. It would certainly be nice to make this all more user friendly (and make hotplug work). The big issue is to fix hotplug. Yes, but this is entirely independent of multifunction devices. Today we shoe-horn hot remove into device_del. Instead, we should have explicit bus-level interfaces for hot remove. Regards, Anthony Liguori I don't see how we can make it user friendly, without making the ordinary case even more unfriendly. Looks like we need yet another level of indirection here. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 02:54 PM, Anthony Liguori wrote: The key is to make the virtio-net devices multifunction and to fill out all 8 functions for each slot. This is unlikely to work right wrt pci hotplug. Yes. Our hotplug design is based on devices.. This is wrong, it should be based on bus-level concepts (like PCI slots). If we want to support a large number of interfaces, we need true multiport cards. This magic here creates a multiport virtio-net card so I'm not really sure what you're suggesting. It would certainly be nice to make this all more user friendly (and make hotplug work). The big issue is to fix hotplug. I don't see how we can make it user friendly, without making the ordinary case even more unfriendly. Looks like we need yet another level of indirection here. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 07:36 AM, Markus Armbruster wrote:
Avi Kivity writes:
On 10/14/2010 12:54 AM, Anthony Liguori wrote:
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
Hi,
Using the legacy way of starting up NICs, I am hitting a limitation
after 29
NICs ie no more than 29 are detected (that's because of the 32 PCI slot
limit on a single bus- 3 are already taken up)
I had initially increased the MAX_NICS to 48, just on my tree, to get to
more, but ofcource that wont work.
Is there any way to go beyond 29 NICs the legacy way? What is the
maximum
that can be supported by the qdev mothod?
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill
out all 8 functions for each slot.
I'm amazed that works. Can't see how creating another qdev in the same
slot makes a proper multifunction device.
multifunction=on sets the multifunction bit for the PCI device. Then
it's a matter of setting the address to be a specific function.
Our default platform devices are actually multifunction.
This is unlikely to work right wrt pci hotplug. If we want to support
a large number of interfaces, we need true multiport cards.
Indeed. As far as I know, we can't hot plug multifunction PCI devices.
Yup.
Regards,
Anthony Liguori
What's the motivation for such a huge number of interfaces?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 07:10 AM, Daniel P. Berrange wrote:
On Thu, Oct 14, 2010 at 02:07:17PM +0200, Avi Kivity wrote:
On 10/14/2010 12:54 AM, Anthony Liguori wrote:
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
Hi,
Using the legacy way of starting up NICs, I am hitting a limitation
after 29
NICs ie no more than 29 are detected (that's because of the 32 PCI slot
limit on a single bus- 3 are already taken up)
I had initially increased the MAX_NICS to 48, just on my tree, to get to
more, but ofcource that wont work.
Is there any way to go beyond 29 NICs the legacy way? What is the
maximum
that can be supported by the qdev mothod?
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill
out all 8 functions for each slot.
This is unlikely to work right wrt pci hotplug. If we want to support a
large number of interfaces, we need true multiport cards.
Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
any type of device we emulate.
I've always been sceptical of this. When physical systems have a large
number of NICs, it's via multiple functions, not a bunch of PCI bridges.
With just a handful of 8-port NICs, you can exceed the current
slot-based limit on physical hardware. It's not an extremely common
configuration but it does exist.
BTW, I don't think it's possible to hot-add physical functions. I
believe I know of a card that supports dynamic add of physical functions
(pre-dating SR-IOV).
Regards,
Anthony Liguori
Daniel
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 07:07 AM, Avi Kivity wrote:
On 10/14/2010 12:54 AM, Anthony Liguori wrote:
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
Hi,
Using the legacy way of starting up NICs, I am hitting a limitation
after 29
NICs ie no more than 29 are detected (that's because of the 32 PCI slot
limit on a single bus- 3 are already taken up)
I had initially increased the MAX_NICS to 48, just on my tree, to
get to
more, but ofcource that wont work.
Is there any way to go beyond 29 NICs the legacy way? What is the
maximum
that can be supported by the qdev mothod?
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill
out all 8 functions for each slot.
This is unlikely to work right wrt pci hotplug.
Yes. Our hotplug design is based on devices.. This is wrong, it should
be based on bus-level concepts (like PCI slots).
If we want to support a large number of interfaces, we need true
multiport cards.
This magic here creates a multiport virtio-net card so I'm not really
sure what you're suggesting. It would certainly be nice to make this
all more user friendly (and make hotplug work).
Regards,
Anthony Liguori
What's the motivation for such a huge number of interfaces?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
Avi Kivity writes:
> On 10/14/2010 12:54 AM, Anthony Liguori wrote:
>> On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
>>>
>>> Hi,
>>>
>>> Using the legacy way of starting up NICs, I am hitting a limitation
>>> after 29
>>> NICs ie no more than 29 are detected (that's because of the 32 PCI slot
>>> limit on a single bus- 3 are already taken up)
>>> I had initially increased the MAX_NICS to 48, just on my tree, to get to
>>> more, but ofcource that wont work.
>>> Is there any way to go beyond 29 NICs the legacy way? What is the
>>> maximum
>>> that can be supported by the qdev mothod?
>>
>> I got up to 104 without trying very hard using the following script:
>>
>> args=""
>> for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
>> for fn in 0 1 2 3 4 5 6 7; do
>> args="$args -netdev user,id=eth${slot}_${fn}"
>> args="$args -device
>> virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
>> done
>> done
>>
>> x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
>> -enable-kvm
>>
>> The key is to make the virtio-net devices multifunction and to fill
>> out all 8 functions for each slot.
I'm amazed that works. Can't see how creating another qdev in the same
slot makes a proper multifunction device.
> This is unlikely to work right wrt pci hotplug. If we want to support
> a large number of interfaces, we need true multiport cards.
Indeed. As far as I know, we can't hot plug multifunction PCI devices.
> What's the motivation for such a huge number of interfaces?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On Thu, Oct 14, 2010 at 02:07:17PM +0200, Avi Kivity wrote:
> On 10/14/2010 12:54 AM, Anthony Liguori wrote:
> >On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
> >>
> >>Hi,
> >>
> >>Using the legacy way of starting up NICs, I am hitting a limitation
> >>after 29
> >>NICs ie no more than 29 are detected (that's because of the 32 PCI slot
> >>limit on a single bus- 3 are already taken up)
> >>I had initially increased the MAX_NICS to 48, just on my tree, to get to
> >>more, but ofcource that wont work.
> >>Is there any way to go beyond 29 NICs the legacy way? What is the
> >>maximum
> >>that can be supported by the qdev mothod?
> >
> >I got up to 104 without trying very hard using the following script:
> >
> >args=""
> >for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
> >for fn in 0 1 2 3 4 5 6 7; do
> >args="$args -netdev user,id=eth${slot}_${fn}"
> >args="$args -device
> >virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
> >done
> >done
> >
> >x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
> >-enable-kvm
> >
> >The key is to make the virtio-net devices multifunction and to fill
> >out all 8 functions for each slot.
>
> This is unlikely to work right wrt pci hotplug. If we want to support a
> large number of interfaces, we need true multiport cards.
Or a PCI bridge to wire up more PCI buses, so we raise the max limit for
any type of device we emulate.
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/14/2010 12:54 AM, Anthony Liguori wrote:
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
Hi,
Using the legacy way of starting up NICs, I am hitting a limitation
after 29
NICs ie no more than 29 are detected (that's because of the 32 PCI slot
limit on a single bus- 3 are already taken up)
I had initially increased the MAX_NICS to 48, just on my tree, to get to
more, but ofcource that wont work.
Is there any way to go beyond 29 NICs the legacy way? What is the
maximum
that can be supported by the qdev mothod?
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill
out all 8 functions for each slot.
This is unlikely to work right wrt pci hotplug. If we want to support a
large number of interfaces, we need true multiport cards.
What's the motivation for such a huge number of interfaces?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Hitting 29 NIC limit
On 10/13/2010 05:32 PM, Anjali Kulkarni wrote:
Hi,
Using the legacy way of starting up NICs, I am hitting a limitation after 29
NICs ie no more than 29 are detected (that's because of the 32 PCI slot
limit on a single bus- 3 are already taken up)
I had initially increased the MAX_NICS to 48, just on my tree, to get to
more, but ofcource that wont work.
Is there any way to go beyond 29 NICs the legacy way? What is the maximum
that can be supported by the qdev mothod?
I got up to 104 without trying very hard using the following script:
args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
args="$args -netdev user,id=eth${slot}_${fn}"
args="$args -device
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done
x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args}
-enable-kvm
The key is to make the virtio-net devices multifunction and to fill out
all 8 functions for each slot.
Regards,
Anthony Liguori
Thanks
Anjali
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hitting 29 NIC limit
Hi, Using the legacy way of starting up NICs, I am hitting a limitation after 29 NICs ie no more than 29 are detected (that's because of the 32 PCI slot limit on a single bus- 3 are already taken up) I had initially increased the MAX_NICS to 48, just on my tree, to get to more, but ofcource that wont work. Is there any way to go beyond 29 NICs the legacy way? What is the maximum that can be supported by the qdev mothod? Thanks Anjali -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NIC limit
>The PCI bus has only 32 slots (devices), 3 taken by chipset + vga, and >a 4th if you have, for example, a virtio disk. Are you sure these are >33 PCI devices and not 33 PCI functions? No, not sure. Apparently my statement was based on an uninformed assumption. I tested using a VM that had 30 (removable-per-web-interface) attachments, and added 3x IDE HDDs to bring it above what I thought was 32 devices: 28 virtio NICs 1 IDE CD-ROM 1 virtio HDD +3 IDE HDDs I could add IDE up past 32 and it would start, as soon as there were more than 28 NICs with or without the 3 IDE HDDs, start would fail. On Wed, 06 Oct 2010 10:18 -0700, "Chris Wright" wrote: > * linux_...@proinbox.com (linux_...@proinbox.com) wrote: > > Hi again everybody, > > > > One of the admins at the ProxmoxVE project was gracious enough to > > quickly release a package including the previously discussed change to > > allow up to 32 NICs in qemu. > > You mean they patched qemu to increase the MAX_NICS constant? Nice to > get the quick turn around. > > Te better choice is to use a newer command line. Not only does it avoid > the MAX_NICS limitation, but it also enables standard virtio-net offload > accelerations. > > > For future reference the .deb is here: > > ftp://download.proxmox.com/debian/dists/lenny/pvetest/binary-amd64/pve-qemu-kvm_0.12.5-2_amd64.deb > > > > Upon creating & running the VM with the newly patched qemu-kvm app > > installed, I found a NIC limitation remained in place, presumably > > imposed by some other aspect of the environment. > > > > The machine would start when it had 33 PCI devices, as long as no more > > than 28 of them were NICs. > > The PCI bus has only 32 slots (devices), 3 taken by chipset + vga, and > a 4th if you have, for example, a virtio disk. Are you sure these are > 33 PCI devices and not 33 PCI functions? > > thanks, > -chris > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit - patch - places limit at 32
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> BTW, using -device, it should be possible to add a very high number of
> nics because you can specify the PCI address including a function. If
> this doesn't Just Work today, we should make it work.
Should work...test...mostly[1], but I don't actually know of any tools that
make use of it.
thanks,
-chris
[1] 40 worked, 48 caused guest kernel stack corruption, didn't dig in to
see why yet.
Here's my simple wrapper to build up the command line:
QEMU=/home/chrisw/git/kvm/qemu-kvm/x86_64-softmmu/qemu-system-x86_64
BIOS=/home/chrisw/git/kvm/qemu-kvm/pc-bios
DISK=/home/chrisw/disk-snap1.img
SCRIPT=/home/chrisw/git/kvm/qemu-kvm/kvm/scripts/qemu-ifup
unset NETARGS
i=0
dev=4
func=0
max_dev=40
while [ $i -lt $max_dev ]
do
unset MULTIFUNC
if [ $(($i + 1)) -lt $max_dev -a $func -eq 0 ]; then
MULTIFUNC=",multifunction=on"
fi
NETARGS="${NETARGS} -netdev type=tap,id=netdev$i,script=$SCRIPT -device
virtio-net-pci,mac=52:54:00:12:34:$(printf "%.2x\n"
$i),netdev=netdev$i,bus=pci.0,addr=$dev.$func$MULTIFUNC"
i=$(($i+1))
func=$(($func+1))
if [ $func -eq 8 ]; then
func=0
dev=$(($dev+1))
fi
done
$QEMU -L $BIOS -m 1024 -drive file=$DISK,if=virtio,boot=on $NETARGS -vnc :0
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NIC limit
* linux_...@proinbox.com (linux_...@proinbox.com) wrote: > Hi again everybody, > > One of the admins at the ProxmoxVE project was gracious enough to > quickly release a package including the previously discussed change to > allow up to 32 NICs in qemu. You mean they patched qemu to increase the MAX_NICS constant? Nice to get the quick turn around. Te better choice is to use a newer command line. Not only does it avoid the MAX_NICS limitation, but it also enables standard virtio-net offload accelerations. > For future reference the .deb is here: > ftp://download.proxmox.com/debian/dists/lenny/pvetest/binary-amd64/pve-qemu-kvm_0.12.5-2_amd64.deb > > Upon creating & running the VM with the newly patched qemu-kvm app > installed, I found a NIC limitation remained in place, presumably > imposed by some other aspect of the environment. > > The machine would start when it had 33 PCI devices, as long as no more > than 28 of them were NICs. The PCI bus has only 32 slots (devices), 3 taken by chipset + vga, and a 4th if you have, for example, a virtio disk. Are you sure these are 33 PCI devices and not 33 PCI functions? thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit - patch - places limit at 32
It's 8 otherwise- and after the patch is applied, it still only goes to 28 for some reason. 28's acceptable for my needs, so I'll step aside from here & leave it to the experts. As for the new -device method, that's all fine & good but AFAIK it's not implemented on my platform, so this was the answer. On Wed, 06 Oct 2010 07:54 -0500, "Anthony Liguori" wrote: > On 10/06/2010 12:46 AM, linux_...@proinbox.com wrote: > > Attached is a patch that allows qemu to have up to 32 NICs, without > > using the qdev -device method. > > > > I'd rather there be no fixed limit and we validate that when add fails > because there isn't a TCP slot available, we do the right thing. > > BTW, using -device, it should be possible to add a very high number of > nics because you can specify the PCI address including a function. If > this doesn't Just Work today, we should make it work. > > Regards, > > Anthony Liguori > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
NIC limit
Hi again everybody, One of the admins at the ProxmoxVE project was gracious enough to quickly release a package including the previously discussed change to allow up to 32 NICs in qemu. For future reference the .deb is here: ftp://download.proxmox.com/debian/dists/lenny/pvetest/binary-amd64/pve-qemu-kvm_0.12.5-2_amd64.deb Upon creating & running the VM with the newly patched qemu-kvm app installed, I found a NIC limitation remained in place, presumably imposed by some other aspect of the environment. The machine would start when it had 33 PCI devices, as long as no more than 28 of them were NICs. This is still a vast improvement compared to the previous limit of 8 NICs, and is very good news for my project. I post here in hopes that maybe someone will come across the link in a search and have a solution. More likely however the new API will be in place and widely in use by then, but whatever. Either way, thanks for your help yesterday. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit - patch - places limit at 32
Attached is a patch that allows qemu to have up to 32 NICs, without using the qdev -device method. max_nics.patch Description: Binary data
Re: 8 NIC limit
* linux_...@proinbox.com (linux_...@proinbox.com) wrote: > I don't know how to make the determination, but it makes sense to me for > the limit defined here to be indicitive of an actual limitation, rather > than what seems an arbitrary best-guess as to the most someone might > need. The actual limitation is that we have only a single PCI bus. The network devices are single function devices. While there are 32 slots on the PCI bus, a few are already taken (typically the first 3, leaving 29 free slots). But, as Markus mentioned, this limitation is only for legacy command line option. The modern qdev way[1] should not hit this same limitation. thanks, -chris [1] http://www.linux-kvm.org/page/Qdev_status -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit
On 10/5/2010 9:48 AM, linux_...@proinbox.com wrote: Hello list: I'm working on a project that calls for the creation of a firewall in KVM. While adding a 20-interface trunk of virtio adapters to bring in a dual 10GB bond, I've discovered an 8 NIC limit in QEMU. I found the following thread in the list archives detailing a similar problem: http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 It includes a patch for the file qemu/net.h to allow 24 NICs: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm";>qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch In my case I want to attach 29, and have simply changed line 8 to 30 from 24. I'd guess you'll bump into a pci device number limit (I believe it is 32 at the moment). This will be the first patch I've ever had to do, and so far my internet search yields results that don't seem to apply. Would someone like to recommend a pertinent tutorial? Many thanks -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit
> Have you tried creating NICs with -device? I'm not sure what that is, will look into it, thanks. I'm using ProxmoxVE, and currently add them via a web interface. Someone happens to host a screenshot of that part here: http://c-nergy.be/blog/wp-content/uploads/Proxmox_Net2.png On Tue, 05 Oct 2010 17:57 +0200, "Markus Armbruster" wrote: > linux_...@proinbox.com writes: > > > Hello list: > > > > I'm working on a project that calls for the creation of a firewall in > > KVM. > > While adding a 20-interface trunk of virtio adapters to bring in a dual > > 10GB bond, I've discovered an 8 NIC limit in QEMU. > > Have you tried creating NICs with -device? The limit shouldn't apply > there. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Re: 8 NIC limit
Forgot to cc list, forwarding. > In this case, I think you're going to want to send your patch to the > qemu-devel (on CC) mailing list (perhaps in addition to sending it > here, to the kvm list). Will do, thanks for the pointer. Before I do so, I'd like to bring up one thing that comes to mind. I don't know how to make the determination, but it makes sense to me for the limit defined here to be indicitive of an actual limitation, rather than what seems an arbitrary best-guess as to the most someone might need. If the change ends up being permanent, then I would hope it would be a large enough value to provide a degree of extensibility and prevent the necessity of bumping it up again later when someone else comes along with even greater bandwidth requirements. Perhaps someone could provide some guidance as to a sane, higher number, as opposed to an arbitrary '65000' which would surely prevent this from happening again (knock on wood). For the time being I still have to find something to help learn how to implement the change locally. I rarely have to compile let alone deal with patches, so to me at least this is a considerable obstacle. -Thanks On Tue, 05 Oct 2010 08:24 -0700, "Dustin Kirkland" wrote: > On Tue, Oct 5, 2010 at 7:48 AM, wrote: > > Hello list: > > > > I'm working on a project that calls for the creation of a firewall in > > KVM. > > While adding a 20-interface trunk of virtio adapters to bring in a dual > > 10GB bond, I've discovered an 8 NIC limit in QEMU. > > > > I found the following thread in the list archives detailing a similar > > problem: > > http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 > > > > It includes a patch for the file qemu/net.h to allow 24 NICs: > > https://bugs.launchpad.net/ubuntu/+source/qemu-kvm";>qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch > > > > In my case I want to attach 29, and have simply changed line 8 to 30 > > from 24. > > > > This will be the first patch I've ever had to do, and so far my internet > > search yields results that don't seem to apply. > > > > Would someone like to recommend a pertinent tutorial? > > Hi there, > > I commented on the original bug in Launchpad. We're willing and able > to carry the patch against qemu-kvm in Ubuntu, I just asked that the > reporter at least submit the patch upstream for discussion. I don't > see where that has happened yet. It's a trivial patch to submit. > Please note in that bug a pointer to the mailing list thread, if you > start one. > > To your specific question, different communities have different > requirements on patch submission, so you do need to consult each > community. A good place to start might be the > Documentation/SubmittingPatches how-to in the kernel tree: > * > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD > > In this case, I think you're going to want to send your patch to the > qemu-devel (on CC) mailing list (perhaps in addition to sending it > here, to the kvm list). > > :-Dustin > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit
linux_...@proinbox.com writes: > Hello list: > > I'm working on a project that calls for the creation of a firewall in > KVM. > While adding a 20-interface trunk of virtio adapters to bring in a dual > 10GB bond, I've discovered an 8 NIC limit in QEMU. Have you tried creating NICs with -device? The limit shouldn't apply there. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 8 NIC limit
On Tue, Oct 5, 2010 at 7:48 AM, wrote: > Hello list: > > I'm working on a project that calls for the creation of a firewall in > KVM. > While adding a 20-interface trunk of virtio adapters to bring in a dual > 10GB bond, I've discovered an 8 NIC limit in QEMU. > > I found the following thread in the list archives detailing a similar > problem: > http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 > > It includes a patch for the file qemu/net.h to allow 24 NICs: > https://bugs.launchpad.net/ubuntu/+source/qemu-kvm";>qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch > > In my case I want to attach 29, and have simply changed line 8 to 30 > from 24. > > This will be the first patch I've ever had to do, and so far my internet > search yields results that don't seem to apply. > > Would someone like to recommend a pertinent tutorial? Hi there, I commented on the original bug in Launchpad. We're willing and able to carry the patch against qemu-kvm in Ubuntu, I just asked that the reporter at least submit the patch upstream for discussion. I don't see where that has happened yet. It's a trivial patch to submit. Please note in that bug a pointer to the mailing list thread, if you start one. To your specific question, different communities have different requirements on patch submission, so you do need to consult each community. A good place to start might be the Documentation/SubmittingPatches how-to in the kernel tree: * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD In this case, I think you're going to want to send your patch to the qemu-devel (on CC) mailing list (perhaps in addition to sending it here, to the kvm list). :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
8 NIC limit
Hello list: I'm working on a project that calls for the creation of a firewall in KVM. While adding a 20-interface trunk of virtio adapters to bring in a dual 10GB bond, I've discovered an 8 NIC limit in QEMU. I found the following thread in the list archives detailing a similar problem: http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 It includes a patch for the file qemu/net.h to allow 24 NICs: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm";>qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch In my case I want to attach 29, and have simply changed line 8 to 30 from 24. This will be the first patch I've ever had to do, and so far my internet search yields results that don't seem to apply. Would someone like to recommend a pertinent tutorial? Many thanks -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
