| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Seeing bridge issues, how do I tell what domU is using w
On Fri, 2005-10-14 at 10:59 +1300, Nicholas Lee wrote:
> On 10/14/05, Ted Kaczmarek <tedkaz@xxxxxxxxxxxxx> wrote:
>
> > Is their a way to get mapping of domU to vif ?
> > Log files don't provide it.
>
>
> nic@wuwei:~$ sudo xm network-list 2
> (1 ((backend-id 0) (mac aa:00:00:88:02:40) (handle 1) (backend
> /local/domain/0/backend/vif/2/1) (tx-ring-ref 521) (rx-ring-ref 522)
> (event-channel 10)))
>
>
> Replaces vif-list
>
> --
> Nicholas Lee
> http://stateless.geek.nz
> gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C
Well that makes it easy :-)
xm create is not creating the interface, cut and dry.
Also appears the domid matches the bridge interface, which is good and
bad. From a snmp standpoint it really sucks when you have moving targets
of instances to deal with, takes the simple part right out of the
protocol as well as adding additional overhead. Would be best if the
domU's could be mapped to a particular bridge interface or at least
reuse the same one.
Definetly some timing related issue also,the faster you try to bring the
domu's up the more of this failure I see. This also harkens back to the
IO contention issue I have when too many domU's are coming from same IO
channel. Weird thing here is the domU gets created but the bridge
interface does not. Doesn't seem to matter what the guest OS is, I run
Centos 4.1, FC4, Debian 3.1, Gentoo 2005 and Slackware 10.3 guests, the
Centos 4.1 and FC4 are my spins the other are jailtime.org, with the
Centos 4.1 being two fatter clients.
The Dom0 is using eth0 for all the domU's with an eth1 as the gateway.
xen_changeset : Thu Oct 13 10:26:44 2005 +0100 7369:92c6021f23e4
Tyan 2462 SMP
Anyone have some 8 gig solid state and controllers they feel like
sending me :-)
Is their something in the test suite for such an animal?
I will try to put something together myself but don't want to spend too
much time reinventing the wheel, puls I also have hardware limitations
that would affect such a testing scenario at present.
Regards,
Ted
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home