<br><font size=2 face="Courier New">When specified at device creation, vifname is put in XenStore directory /local/domain/0/backend/vif/<domID>/<vif_number>. All vifnames used in a domain are returned by Get "/xend/domain/<domID>?detail=1" and converted into XML "target" by virDomainGetXMLDesc.</font>
<br><font size=2 face="Courier New">For convenience, we could force the vifname, either at domain creation or in Attach, and ignore any "target" in "interface", except for Detach. The vifname value could be the sequence number of network device creation in domain (for Xen, it would be equal to vif number).</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Veuillez répondre à "Daniel P. Berrange" <berrange@redhat.com></font>
<p><font size=1 color=#800080 face="sans-serif">Pour :        </font><font size=1 face="sans-serif">michel.ponceau@bull.net</font>
<br><font size=1 color=#800080 face="sans-serif">cc :        </font><font size=1 face="sans-serif">libvir-list@redhat.com</font><font size=1 color=#800080 face="sans-serif"> </font>
<br><font size=1 color=#800080 face="sans-serif">Objet :        </font><font size=1 face="Arial">Re: [Libvir] Proposal for virtual devices described in XML</font>
<br>
<br><font size=2 face="Courier New">On Wed, Sep 27, 2006 at 05:21:33PM +0200, michel.ponceau@bull.net wrote:<br>
> After comments from Daniel P. Berrange and from Bull people, my proposal <br>
> is reduced to following 2 functions:<br>
> <br>
> /* Create a virtual device attachment to backend */<br>
> int virDomainAttachDevice(virDomainPtr domain, char *xml);<br>
<br>
This is definitely a good way forward - it lets us re-use the existing<br>
code for parsing device descriptions very easily.<br>
<br>
> /* Destroy a virtual device attachment to backend */<br>
> int virDomainDetachDevice(virDomainPtr domain, char *xml);<br>
> /* @domain: pointer to domain object<br>
> * @xml: pointer to XML description of one device<br>
> * Returns 0 in case of success, -1 in case of failure. */<br>
<br>
I was wondering whether we need to have the full XML block passed in<br>
for detaching devices. Perhaps it is sufficient to just pass i nthe<br>
target name of the device. Then again, some implementations may prefer<br>
to have the full XML blob available to allow greater sanity checking<br>
when detaching, so its probably worth while.<br>
<br>
> The XML would be in same form as the part of domain description for a <br>
> single device, either <disk.../disk> or <interface.../interface>.<br>
<br>
Very nice.<br>
<br>
> The device is identified by its target name. This attribute is optional <br>
> for "interface" in domain description, but would become mandatory in <br>
> Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source <br>
> xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" <br>
> into Xen "vifname". (It processes "ip" attribute in same way, but my try <br>
> failed, maybe because address value was invalid for Xen).<br>
<br>
I'm not sure I like the idea of having to explicitly set a vif name for<br>
every guest NIC we define - principally because there's no straightforward<br>
way for a user of this API to determine what VIF names are already in use,<br>
vs free. It also seems XenD does not tell us what the vifname for running<br>
domains are - although I think the info is in xenstore somewhere. I can see<br>
why we need the vifname to detach the device though.<br>
<br>
If we can find a way to fill in the vifname when dumping the XML, then this<br>
would let a caller uniquely identify an existing device, without us <br>
requireing that vifnames are used when creating a domain/attaching a new<br>
device (& thus let Xen still auto-allocate them)<br>
<br>
Regards,<br>
Dan.<br>
-- <br>
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|<br>
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|<br>
|=-               Projects: http://freshmeat.net/~danielpb/               -=|<br>
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| <br>
</font>
<br>
<p>