Hello there. I''m used to xen with paravirtualized guests and am now starting to play with HVM guests. When creating an HVM guest I noted that Xen will create two new network interfaces in Dom0: the usual vifX and a new tapY. The vif one can be renamed as usual with vifname= in the config file, and gets added by xen scripts to the corresponding bridge interface (bridge=blah in config). Little problem is, no traffic appears on this interface. The interface actually ''connected'' to the HVM guest is the tap one, which gets a name not associated with the domain id, name or config and doesn''t get added to the bridge. Is this expected behavior in one way or another? How do you people deal with bridged networking and HVM guests (eg. how do you add interfaces to bridges and/or iptables) ? Thanks, -- Luca Lesinigo _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
What Distro/version and Xen version are you running? 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). 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. 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. 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. Dustin -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Luca Lesinigo Sent: Tuesday, August 19, 2008 22:50 To: xen-users@lists.xensource.com Subject: [Xen-users] network setup for HVM guests Hello there. I''m used to xen with paravirtualized guests and am now starting to play with HVM guests. When creating an HVM guest I noted that Xen will create two new network interfaces in Dom0: the usual vifX and a new tapY. The vif one can be renamed as usual with vifname= in the config file, and gets added by xen scripts to the corresponding bridge interface (bridge=blah in config). Little problem is, no traffic appears on this interface. The interface actually ''connected'' to the HVM guest is the tap one, which gets a name not associated with the domain id, name or config and doesn''t get added to the bridge. Is this expected behavior in one way or another? How do you people deal with bridged networking and HVM guests (eg. how do you add interfaces to bridges and/or iptables) ? Thanks, -- Luca Lesinigo _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@luckyluke.org] Sent: Wednesday, August 20, 2008 11:49 To: Dustin.Henning@prd-inc.com 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@lists.xensource.com http://lists.xensource.com/xen-users
Il giorno 22/ago/08, alle ore 17:52, Dustin Henning ha scritto:> 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.*I* am sorry for the wrong reply. This time I got it right :D> -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.I''m currently looking into this. Iptables and other stuff will come only when I''ve got the basic networking in a sane state :) So what I''ve got so far is: - for every HVM guest I get two interfaces created, the usual vifX and the tapX. This is correct. - I can control the vifX name with "vif = [ ''...., vifname=foobar'' ]", but I don''t know if/how to control the name of the tap interface. This would be nice but it''s not required. - every time I boot/reboot an HVM guest the vif-bridge script will add the vifX interface to the bridge, but NOT the tapX. This *IS* the actual problem. My environment: - latest and updated gentoo linux amd64, on HVM enabled hardware, with Xen-3.2.1 compiled from gentoo portage. Everything runs in x86_64 mode. - kernel 2.6.21-xen from gentoo''s xen-sources, tap driver statically linked in kernel, bridge driver as a module - in my hvm guest config, the only network-related stuff I have is: vif = [ ''type=ioemu, mac=00:16:3e:09:01:14, bridge=bridge0, vifname=vif-foobar'' ] - also: pae=0, acpi=1, apic=1, WinXP 32bit guest, no pv drivers (since they''re not "production ready" I''m not looking into them) I added two lines at the beginning of scripts/vif-bridge:> env > /tmp/vif-bridge > echo $* > /tmp/vif-argsso after a guest domain reboot I can see:> # cat /tmp/vif-args > online > # cat /tmp/vif-bridge > SUBSYSTEM=xen-backend > DRIVER=vif > XENBUS_TYPE=vif > DEVPATH=/devices/xen-backend/vif-9-0 > script=/etc/xen/scripts/vif-bridge > vif=vif9.0 > ACTION=online > PWD=/ > UDEV_LOG=3 > XENBUS_PATH=backend/vif/9/0 > UDEVD_EVENT=1 > XENBUS_BASE_PATH=backend > SHLVL=1 > PHYSDEVDRIVER=vif > PHYSDEVBUS=xen-backend > SEQNUM=2136 > _=/usr/bin/envafter all this stuff... I am looking for someone using HVM guests that gets its tapX interfaces correctly added to the bridges, and I''d like to know what ACTUALLY does that adding and how. Which script, or whatever. I''m trying to trace down my problem (could be something in my system, or in xen scripts, or in gentoo''s install of xen, or whatever), but I don''t know where to start because I just don''t know where in the interface between xend and the scripts I should get an indication that there''s a tapX involved with the guest. By the way, I will probably look into upgrading to Xen-3.3.0 since I can do this sort of tests on the system during non-office hours :) Thanks, -- Luca Lesinigo _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Il giorno 10/set/08, alle ore 17:15, Luca Lesinigo ha scritto:> after all this stuff... I am looking for someone using HVM guests > that gets its tapX interfaces correctly added to the bridges, and > I''d like to know what ACTUALLY does that adding and how. Which > script, or whatever. > I''m trying to trace down my problem (could be something in my > system, or in xen scripts, or in gentoo''s install of xen, or > whatever), but I don''t know where to start because I just don''t know > where in the interface between xend and the scripts I should get an > indication that there''s a tapX involved with the guest. > By the way, I will probably look into upgrading to Xen-3.3.0 since I > can do this sort of tests on the system during non-office hours :)I''ll add that: 1) under Xen-3.2.1, even xm list --long <domain_id> will no mention any tap device at all 2) upgraded to Xen-3.3.0, and now at domain creation it correctly adds the tap interface to the bridge! yay, problem solved! Thanks, -- Luca Lesinigo _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users