Luca,
Sorry for the delayed response. It looks like you didn't include
the group in your response, so no one else has seen your added information
below. That said, the primary reason I asked about the versions was in case
someone else could recognize one and mention a known issue. Regarding your
responses:
-It seems likely that the issue with the tap interfaces not being moved
could be script related, but I really don't know, so I was hoping someone
else would have some input.
-It sounds like you might need to get your iptables rules integrated into a
script so they are tied to the proper interface for accounting, depending on
how this is done, assuming the problem with tap interfaces not being bridged
is corrected, this may even allow you to send the tap and vif interfaces to
the same chains (per domU) and effectively monitor all traffic regardless of
whether or not PV drivers are in use.
-Regarding vif and tap interfaces, I think vif interfaces are always created
by design and tap interfaces are added for HVM support. I don't know for
certain whether the existence of both is integral, so it might be that some
configuration to disable unnecessary PV devices could be added in the
future, but I do know that for those of us using PV drivers, especially in
Windows, it is sometimes necessary to switch back to the HVM drivers (for
instance, to update the PV drivers or troubleshoot), and we still need
network access if we do that.
All of that said, assuming that the vif devices aren't integral to tap
functionality, if you know a lot about scripting, you may even be able to
create your own device scripts that don't create the vif interfaces for your
HVMs and it might even be possible to name the tap interfaces in an
identifiable way, but I really don't know, and I assume there is some reason
the tap devices are always 0, 1, 2, 3 etc.
Dustin
-----Original Message-----
From: Luca Lesinigo [mailto:luca@xxxxxxxxxxxxx]
Sent: Wednesday, August 20, 2008 11:49
To: Dustin.Henning@xxxxxxxxxxx
Subject: Re: [Xen-users] network setup for HVM guests
Il giorno 20/ago/08, alle ore 14:33, Dustin Henning ha scritto:
> What Distro/version and Xen version are you running?
I am using Gentoo Linux and both xen and xen-tools installed from
Gentoo Portage. I'll examine the scripts inner workings to check them
out...
> I run HVM guests with bridging and have never had this problem. To
> clarify, while it is true that the tap interfaces don't necessarily
> match the domU IDs the way the default vifX interfaces do, in my
> case, the bridge chosen in the HVM config file always gets both
> interfaces added to it (regardless of whether or not vifname is used).
Mmmm so probably the issue are the scripts that don't do this.
As far as I know the vif interface is completely unused and gets
created for nothing?
> I haven't ever had a need to have more than one bridge, so the fact
> that I couldn't tell which tap interface belonged to which hvm
> wasn't problematic to me, that said, perhaps someone else can shed
> some light on some method of determining which tap interface belongs
> to which domU and/or what commands might affect all interfaces tied
> to a given domU.
My need is to provide personalized firewalling and traffic accounting
for each DomU. I always used iptables to accomplish this (with two IN
& OUT chains for each DomU).
I can actually do the same matching the ip addresses, but it's not the
"ideal" solution, that would getting the actually 'virtual network
cable' to the DomU as represented by the network interface in dom0.
> However, it sounds like you have a bug that needs resolving
> regardless.
> Also, FYI, if you us PV drivers (James Harper's GPLPV for Windows or
> the appropriate Xen kernel drivers for Linux) in your HVMs, you will
> go through the interfaces identified as vifX or via vifname.
I still have to investigate such solutions, I'm sticking to ioemu for
now. So far I haven't seen any stability or performance issue. In my
case the domU traffic is going directly to internet (in a colo
facility) so I don't mind if I can't get true ethernet wirespeed: the
uplink would be slower anyway.
> Also, if you are able to use install such drivers and they don't
> work as expected, it could (though one would certainly hope not, and
> I don't think it would stand
> to reason) be related to the fact that the vifX and tapY interfaces
> aren't on the same bridge, and this might be a bug as well.
So far I know that ioemu interfaces will get traffic through tap
devices in dom0 and PV drivers/interfaces will get traffic through vif
devices. I can't understand why both (vif and tap) get created
regardless of the fact that I only specify one of them in the domU
config. To me looks like the ideal solution would be that xend created
only the interfaces it needs (be it tap o vif) and run the vif-scripts
on those.
--
Luca Lesinigo
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home