Is it possible to programmatically determine the VNIC created for and used by a PV guest? From a shell script? I am looking at the /usr/lib/xen/scripts/vif-vnic script but have no ideas so far. Thank you, Vasiliy
On Fri, Nov 28, 2008 at 04:07:18PM +0300, Vasiliy Baranov wrote:> Is it possible to programmatically determine the VNIC created for > and used by a PV guest? From a shell script? I am looking at the > /usr/lib/xen/scripts/vif-vnic script but have no ideas so far.If you know the domid of the guest then you can find it in xenstore (vif-vnic writes it as ''nic'').
On Fri, Nov 28, 2008 at 01:46:17PM +0000, David Edmondson wrote:> On Fri, Nov 28, 2008 at 04:07:18PM +0300, Vasiliy Baranov wrote: > > Is it possible to programmatically determine the VNIC created for > > and used by a PV guest? From a shell script? I am looking at the > > /usr/lib/xen/scripts/vif-vnic script but have no ideas so far. > > If you know the domid of the guest then you can find it in xenstore > (vif-vnic writes it as ''nic'').In particular, courtesy of ~johnlev/bin/dom2vnic: #!/bin/bash test -n "$1" || exit 1 id=`virsh domid $1` backend=`xenstore-read /local/domain/$id/device/vif/0/backend` echo `xenstore-read $backend/nic` regards john
On 11/28/08 09:39, John Levon wrote:> id=`virsh domid $1` > backend=`xenstore-read /local/domain/$id/device/vif/0/backend` > echo `xenstore-read $backend/nic`Umm, but the xenstore commands aren''t a public interface, are they? - Bob
On Mon, Dec 01, 2008 at 12:37:24PM -0500, Bob Scheifler wrote:> On 11/28/08 09:39, John Levon wrote: >> id=`virsh domid $1` >> backend=`xenstore-read /local/domain/$id/device/vif/0/backend` >> echo `xenstore-read $backend/nic` > > Umm, but the xenstore commands aren''t a public interface, are they?Even if they are, the path in the store isn''t stable - you can''t rely on us not changing it. What''s the problem we''re trying to solve here?
On Mon, Dec 01, 2008 at 12:37:24PM -0500, Bob Scheifler wrote:> On 11/28/08 09:39, John Levon wrote: > >id=`virsh domid $1` > >backend=`xenstore-read /local/domain/$id/device/vif/0/backend` > >echo `xenstore-read $backend/nic` > > Umm, but the xenstore commands aren''t a public interface, are they?That''s correct. It''s a hack, not a reliable interface. (An RFE for the latter would be fine...) regards john
David Edmondson wrote:> On Mon, Dec 01, 2008 at 12:37:24PM -0500, Bob Scheifler wrote: > >> On 11/28/08 09:39, John Levon wrote: >> >>> id=`virsh domid $1` >>> backend=`xenstore-read /local/domain/$id/device/vif/0/backend` >>> echo `xenstore-read $backend/nic` >>> >> Umm, but the xenstore commands aren''t a public interface, are they? >> > > Even if they are, the path in the store isn''t stable - you can''t rely > on us not changing it. > > What''s the problem we''re trying to solve here?First of all, I have to say, the original question was about obtaining the VNIC used by a running guest, and the answer worked and was very educational. Thank you. In fact, it looks like our ultimate goal here is we need to be able to additionally configure the VNIC created for a guest before the guest is even started. "Additionally configure" could include adding IP Filter rules, Crossbow properties, etc. To do so, do we need to hack /usr/lib/xen/scripts/vif-vnic? Or can we create VNICs ourselves and use e.g. /usr/lib/xen/scripts/vif-dedicated to pass them to xVM? What would be the recommended mechanism, in both xm and virsh realms? Are there any hook scripts called on VNIC creation/destruction intended specifically for this, maybe? Thank you, Vasiliy
On Mon, Dec 01, 2008 at 11:59:17PM +0300, Vasiliy Baranov wrote:> In fact, it looks like our ultimate goal here is we need to be able > to additionally configure the VNIC created for a guest before the > guest is even started. "Additionally configure" could include adding > IP Filter rules, Crossbow properties, etc. To do so, do we need to > hack /usr/lib/xen/scripts/vif-vnic? Or can we create VNICs ourselves > and use e.g. /usr/lib/xen/scripts/vif-dedicated to pass them to xVM? > What would be the recommended mechanism, in both xm and virsh > realms? Are there any hook scripts called on VNIC > creation/destruction intended specifically for this, maybe?The xVM Server BUI team chose to create the VNIC first and use vif-dedicated. Rate limits can be specified in the .py files for xm, but not with virsh. These aren''t applied yet, but will start to work when Crossbow is integrated. There are no hooks to apply filtering, etc. If you can describe what you need we may look at adding a hook mechanism to the scripts.
David Edmondson wrote:> On Mon, Dec 01, 2008 at 11:59:17PM +0300, Vasiliy Baranov wrote: > >> In fact, it looks like our ultimate goal here is we need to be able >> to additionally configure the VNIC created for a guest before the >> guest is even started. "Additionally configure" could include adding >> IP Filter rules, Crossbow properties, etc. To do so, do we need to >> hack /usr/lib/xen/scripts/vif-vnic? Or can we create VNICs ourselves >> and use e.g. /usr/lib/xen/scripts/vif-dedicated to pass them to xVM? >> What would be the recommended mechanism, in both xm and virsh >> realms? Are there any hook scripts called on VNIC >> creation/destruction intended specifically for this, maybe? >> > > The xVM Server BUI team chose to create the VNIC first and use > vif-dedicated. > > Rate limits can be specified in the .py files for xm, but not with > virsh. These aren''t applied yet, but will start to work when Crossbow > is integrated. > > There are no hooks to apply filtering, etc. If you can describe what > you need we may look at adding a hook mechanism to the scripts.We need to be able to setup IP Filter rules: ipf -f - <<EOF pass in on vnic100 from a.b.c.0/d to any layer2 pass in on vnic100 from e.f.g.0/h to any layer2 pass in on vnic100 from i.j.k.0/l to any layer2 count in on vnic100 from x.y.0.0/z to any layer2 count out on vnic100 from any to x.y.0.0/z layer2 EOF add Crossbow flows: flowadm add-flow -l vnic100 -a remote_ip=a.b.c.0/d myflow1 flowadm add-flow -l vnic100 -a remote_ip=e.f.g.0/h myflow2 specify CPU binding: dladm set-linkprop -o cpus=0,1 vnic100 and maybe do some more (sorry, I don''t think I can foresee all the requirements) before the guest starts using the VNIC. We also need to be able to cleanup things when the guest is destroyed. Rate limits can be useful but do not cover everything. Hooks can be useful, but there is a question of passing all app-specific information to the hook scripts. So perhaps vif-dedicated is the ideal method. The question is, are there any special things that need to be done to a VNIC to make it usable by an xVM guest? That is, if I create a VNIC with: dladm create-vnic -l bge0 vnic100 and, when starting the guest, specify the VNIC as ''bridge'' and /usr/lib/xen/scripts/vif-dedicated as ''script'', will the VNIC work as if it was created by vif-nic? Thank you, Vasiliy
On Tue, Dec 02, 2008 at 01:39:44PM +0300, Vasiliy Baranov wrote:> So perhaps vif-dedicated is the ideal method. The question is, are there > any special things that need to be done to a VNIC to make it usable by > an xVM guest? That is, if I create a VNIC with: > > dladm create-vnic -l bge0 vnic100 > > and, when starting the guest, specify the VNIC as ''bridge'' and > /usr/lib/xen/scripts/vif-dedicated as ''script'', will the VNIC work as if > it was created by vif-nic?Yes.
David Edmondson wrote:> On Tue, Dec 02, 2008 at 01:39:44PM +0300, Vasiliy Baranov wrote: > >> So perhaps vif-dedicated is the ideal method. The question is, are there >> any special things that need to be done to a VNIC to make it usable by >> an xVM guest? That is, if I create a VNIC with: >> >> dladm create-vnic -l bge0 vnic100 >> >> and, when starting the guest, specify the VNIC as ''bridge'' and >> /usr/lib/xen/scripts/vif-dedicated as ''script'', will the VNIC work as if >> it was created by vif-nic? >> > > Yes.Great. Thank you very much, Vasiliy