[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Number of NICs per VM with qemu-upstream (Was: Re: Re: libvirt <emulator> /usr/local/lib/xen/bin/qemu-dm <emulator> did not work on xen-4.4)



On Thu, 20 Nov 2014, Ian Campbell wrote:
> On Thu, 2014-11-20 at 11:39 +0000, Stefano Stabellini wrote:
> > On Thu, 20 Nov 2014, Ian Campbell wrote:
> > > On Mon, 2014-11-17 at 13:00 +0000, Stefano Stabellini wrote:
> > > > On Mon, 17 Nov 2014, Ian Campbell wrote:
> > > > > On Sat, 2014-11-15 at 10:16 +0800, hanyandong wrote:
> > > > > > By the way, how many NICs can I apply to a VM?
> > > > > > 
> > > > > > On xen-4.4.0, Using qemu-dm, I can apply 8 NIC to a VM, but using
> > > > > > qemu-system-i386, I can only apply 4 NICs to an VM?
> > > > > > is it normal?
> > > > > 
> > > > > I've no idea, CCing the qemu maintainers.
> > > > > 
> > > > > I'd have expected the number of PV nics to be completely independent 
> > > > > of
> > > > > the device mode, so I suppose you mean emulated NICs?
> > > > 
> > > > I can pass 4 emulated NICs maximum, but you can easily reach 8 if you
> > > > use PV NICs instead. Just pass 'type=pv' like this:
> > > > 
> > > > vif=['', '', '', '', 'type=pv', 'type=pv', 'type=pv', 'type=pv']
> > > > 
> > > > it is going to create 4 emulated nics and 4 pv nics. The 4 emulated nics
> > > > also have 4 corresponding pv nics. The emulated nics get disconnected
> > > > soon after boot by the guest operating system (if it has pv drivers
> > > > installed, such as Linux). So overall once the boot sequence is fully
> > > > completed you'll end up with the 8 pv nics that you want.
> > > 
> > > I wonder if we should do something in (lib)xl such that by default the
> > > first 4 NICs have type LIBXL_NIC_TYPE_VIF_IOEMU (i.e. emulated+PV path)
> > > and the rest have LIBXL_NIC_TYPE_VIF (i.e. PV only).
> > 
> > That looks like a simple and reasonable idea.
> > 
> > 
> > > > BTW the reason for the failure seems to be that QEMU runs out of ram
> > > > (xen: failed to populate ram at 80110000, so
> > > > xc_domain_populate_physmap_exact failed) allocating roms for the rtl8139
> > > > (40000 bytes each). Maybe qemu-trad wasn't loading any roms for rtl8139.
> > > > Interestingly e1000 doesn't need any roms either, so another way around
> > > > this would be to set 'type=e1000' for all the vifs.
> > > 
> > > Or to use the new option in 4.5 to increase the MMIO space (or is that
> > > not where ROMs end up?)
> > > 
> > > Do we need to plumb through qemu's optionrom parameter to allow a)
> > > limiting the number of NICs which will try to do PXE and b) allow custom
> > > roms etc?
> > 
> > The libxl solution is the best one for simplicity, besides I don't think
> > there is such an option for QEMU.
> 
> There is, it's the romfile option to -device e.g.
>          -device $NICMODEL,vlan=0,romfile=$ROMFILE
>         
> where NICMODEL is e100, rtl8139, virtio-blah
> and ROMFILE is e.g. an ipxe binary.

I think that option was intended to point QEMU to a different file, not
to disable the romfile.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.