qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Nic devices' name are wrongly repeated


From: Amos Kong
Subject: Re: [Qemu-devel] Nic devices' name are wrongly repeated
Date: Wed, 10 Apr 2013 22:17:04 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Apr 10, 2013 at 02:28:40PM +0200, Andreas Färber wrote:
> Hi,
> 
> Am 10.04.2013 14:05, schrieb Amos Kong:
> > If we don't assign 'id' for nic device, device name will be $model.$idx. 
> > The $idx are always 0 if we set nic by new style.
> > 
> > # qemu-upstream -device virtio-net-pci,netdev=h1 -netdev tap,id=h1 -device 
> > virtio-net-pci,netdev=h2 -netdev tap,id=h2 ...
> > (qemu) info network
> > virtio-net-pci.0: 
> > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >  \ h1: 
> > index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
> > virtio-net-pci.0: 
> > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
> >  \ h2: 
> > index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
> > 
> > it's introduced by commit d33d93b2
> 
> I can see that's inconvenient, but...
> 
> > If we set links down by 'set_link virtio-net-pci.0', the first nic
> > will be set down. But how to set the second link down by id?
> 
> As you would do for all devices? I.e., add ,id=youruniqueid to -device.

If we also assigned unique ids for nic devices, it works.
 
> Having said that, in a different context (USB) I was made aware that we
> don't know the bus name at QOM initialization time yet and, if we want
> to create a bus at that point, will need to rename it later. Thus we'd
> need an overridable ID setter hook to propagate to busses, and if we had
> such a settable ID property it would be convenient for your use case to
> have a matching monitor command as well to be able to resolve name
> conflicts at runtime rather than with a QEMU restart.

It's better to allocate an increased & uniqued index suffix
automatically as past. monitor command is good for human, but
it's difficult for management tools to identify & resolve the
conflicts.
 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
                        Amos.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]