WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] correlation of HVM tapX devices to domain

To: Steven Maresca <lightyear4@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] correlation of HVM tapX devices to domain
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 07 Apr 2008 11:43:32 +0100
Cc: James Harper <james.harper@xxxxxxxxxxxxxxxx>, Mark Price <mprice@xxxxxxxxxxxxx>, Christian Horn <chorn@xxxxxxxxxxxx>, "Max E. Baro" <MEB@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Apr 2008 03:44:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <7e9718f20804070331n5d187e9atad744c39a645049d@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciYnDkUd6wAvQSPEd2dHwAX8io7RQ==
Thread-topic: [Xen-devel] [RFC] correlation of HVM tapX devices to domain
User-agent: Microsoft-Entourage/11.4.0.080122
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

<Prev in Thread] Current Thread [Next in Thread>