I think this is addressed by xen-unstable changeset 17208.
-- Keir
On 7/4/08 11:31, "Steven Maresca" <lightyear4@xxxxxxxxx> wrote:
> Hello all.
>
> This message is a request-for-comments regarding a common issue with
> fully virtualized domUs. Individuals carbon copied have expressed
> interest in the issue recently and in the past. It may eventually be
> beneficial to cross-post to xen-users, but I suspect that xen-devel is
> the proper venue for now.
>
> Specifically, I am inquiring about the correlation of tapX network
> devices to the relevant HVM domains. At present such correlation is
> not possible, though I will propose some solutions. If this problem or
> any facets have already been addressed in recent changesets, I
> apologize, but I do not believe that to be the case. Regardless, this
> should remain relevant for those with existing installations.
>
> Following the body of this message, I am including a bash function
> with instructions for an accurate workaround in qemu-ifup. A possible
> patch to the existing qemu code that creates the tap device is
> suggested, seeking comment.
>
> Some summary of behavior:
> 1.) These devices are generated by qemu-dm, are not managed by the
> vif-* scripts, and at present do not have any representation in
> xenstore.
> 2.) Unlike the vifDOMID.IFNUM naming conventions of devices for
> paravirtual network interfaces, these emulated devices are simply
> tapX, with corresponding loosely to the number of HVM domains and
> number of emulated interfaces per domain.
> 3.) The vifname parameter when specified in a domU configuration
> applies only to paravirtual network interfaces; it is not applied to
> the tap
>
> The implications include difficulty for firewalling, inability to
> accurately monitor domains at an interface level, and divergence of
> semantics between paravirtual and HVM domains.
>
> Further (tangentally) complicating the issue are the paths by which
> HVM network vifX.Y and tapX interfaces are created, as summarized in
> this posting by Dan Berrange:
> http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00160.html
> : The lack of a type= definition for the vif(s) causes both ioemu and
> PV interfaces to be created; the vifname parameter is applied only to
> the interface for the paravirtual networking (obviously if two
> interfaces are created, the vifname is of little use anyway due to a
> lack of uniqueness).
>
> ---
>
> With all of that said: In the interest of being noninvasive and
> maintaining existing behaviors that some may rely upon, I would
> suggest two possible solutions.
>
> 1) A workaround using the qemu-ifup script, tested and accurate. It
> is called directly by the qemu-dm process, and thus, the $PPID
> variable set at runtime in the script directly correlates with the PID
> of the qemu-dm process of the related domain. Likewise, the first
> field of the $* variable contains the tap interface name. Parsing the
> DOMID of the domain from qemu-dm's arguments, we can then write the
> information to xenstore. I currently use the following path:
> /local/domain/${DOMID}/device/vif-ioemu . This option would integrate
> easily with existing installations and is valid for multiple ioemu
> interfaces. Function and usage follows the body of this message.
>
> 2) A patch to tools/ioemu/vl.c in the net_tap_init() function which
> accomplishes the same as above in a more appropriate place. The same
> may be relevant in the vnet code where tap_open() is called. *Provided
> that this route is agreeable, I will create the patch and followup to
> this message.
>
> Other possible solutions might include patching net_tap_init() to use
> the appropriate vif-script to bring behavior closer to paravirtual
> machines, but this would touch many places in the code and may not be
> desirous. Alternatively or in conjunction, it may be beneficial to
> apply the vifname parameter both to the PV vif and to the ioemu tap
> device (with an "ioemu" suffix or something similar).
>
> Notes for completeness:
>
> The following thread from October 2007 "How to tell which tapX
> interface belongs to which domain" addressed the topic and arrived at
> a usable solution, yet is not necessarily ideal given the many
> possible sources of error.
> http://lists.xensource.com/archives/html/xen-users/2007-10/msg00208.html
>
> The following recently submitted patch attempted to address this issue
> supervficially in image.py, but (as it both lacks any xenstore
> association and is several layers above the origin of the device
> name), I'm not quite sure its the right way to approach the problem:
> http://lists.xensource.com/archives/html/xen-devel/2008-03/msg00305.html
>
> ---
>
> Comments, criticisms, and suggestions welcomed.
>
> Thanks,
> Steven Maresca
>
>
>
>
> Workaround using qemu-ifup. Add the below function to qemu-ifup (or
> source a file containing it), and place the following two lines at the
> very bottom of the qemu-ifup script.
>
> IFACE=`echo $* | awk '{print $1}'`
> saveHVMif ${PPID} ${IFACE}
>
>
> #inelegant but accurate
> saveHVMif () {
> PARENTPID=$1
> IF=$2
>
> flagnum=0;
> for i in $QEMUARGS;
> do
>
> flagnum=`expr $flagnum + 1`
> if [ "${i}" == "-domain-name" ]; then
> nameflag=0;
> nameflag=`expr $flagnum + 1`;
> NAME=`echo $QEMUARGS | awk '{print $'$nameflag'}'`;
> fi;
> done;
> DOMID=`xm list ${NAME} | grep ${NAME} | awk '{print $2}'`
> TOSAVE="${IF}"
> OLDVAL=`xenstore-read /local/domain/${DOMID}/device/vif-ioemu`
>
> if [ $? -ne 1 ]; then
> for val in $OLDVALS; do
> if [ "${val}" == "${IF}" ]; then
> IF=""
> fi
> done
> if [ "${IF}" != "" ]; then
> TOSAVE="${IF},${OLDVAL}"
> else
> TOSAVE="${OLDVAL}"
> fi
> fi
> xenstore-write /local/domain/${DOMID}/device/vif-ioemu "${TOSAVE}"
> };
>
>
>
>
>
> ------------------------------------------------------------------------------
> ----
> ------------------------------------------------------------------------------
> ----
> ------------------------------------------------------------------------------
> ----
> http://zentific.com - Xen web management, coming soon!
> ------------------------------------------------------------------------------
> ----
> ------------------------------------------------------------------------------
> ----
> ------------------------------------------------------------------------------
> ----
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home