[zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
Hi, I have a customer who has a basic IPMP config in his global zone: vnet0 & vnet1 [currently vnet0 has the 'floating' IP] In addition he has a zone with ip-type=shared where physical=vnet1 When the zone boots the zone interface gets created on vnet0 instead of vnet1 I have verified this behaviour on a test system and can confirm that the zone interface acts in the same way as the floating IP. i.e. if I run 'if_mpadm -d vnet0', then the zone's IP fails over to vnet1 Unfortunately I can't find any documentation that discusses this behaviour. Is anybody aware of any documents that explain what we are seeing? Thanks, Lewis ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
This appears to be the affect of selecting an interface that is a member of an ipmp group in the global zone. It is documented here: http://docs.sun.com/app/docs/doc/819-2450/z.admin.task-60?l=ko&a=view&q=multipathing The behavior you are seeing is not specifically documented, but it seems reasonable. What behavior are you expecting? -Steve L. On Tue, May 20, 2008 at 03:20:04PM +0100, Lewis Thompson wrote: > Hi, > > I have a customer who has a basic IPMP config in his global zone: > >vnet0 & vnet1 [currently vnet0 has the 'floating' IP] > > In addition he has a zone with ip-type=shared where physical=vnet1 > > When the zone boots the zone interface gets created on vnet0 instead of > vnet1 > > I have verified this behaviour on a test system and can confirm that the > zone interface acts in the same way as the floating IP. i.e. if I run > 'if_mpadm -d vnet0', then the zone's IP fails over to vnet1 > > Unfortunately I can't find any documentation that discusses this > behaviour. Is anybody aware of any documents that explain what we are > seeing? > > Thanks, Lewis > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
On Tue, 2008-05-20 at 13:56 -0700, Steve Lawrence wrote: > It is documented here: > > http://docs.sun.com/app/docs/doc/819-2450/z.admin.task-60?l=ko&a=view&q=multipathing > > The behavior you are seeing is not specifically documented, but it seems > reasonable. What behavior are you expecting? Hi Steve, For now I am just looking for confirmation that this is expected behaviour. However, as the customer has specifically set physical equal to the other interface in the IPMP group, I would expect this to be used, when the interface is not in a FAILED state. Thanks, Lewis ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
In the global zone, do you have two ip addresses (one on vnet0, one on vnet1) or is vnet1 configured as standby? Steve L. On Wed, May 21, 2008 at 09:12:35AM +0100, Lewis Thompson wrote: > On Tue, 2008-05-20 at 13:56 -0700, Steve Lawrence wrote: > > It is documented here: > > > > http://docs.sun.com/app/docs/doc/819-2450/z.admin.task-60?l=ko&a=view&q=multipathing > > > > The behavior you are seeing is not specifically documented, but it seems > > reasonable. What behavior are you expecting? > > Hi Steve, > > For now I am just looking for confirmation that this is expected behaviour. > > However, as the customer has specifically set physical equal to the > other interface in the IPMP group, I would expect this to be used, when > the interface is not in a FAILED state. > > Thanks, Lewis > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
Lewis Thompson wrote: > Hi, > > I have a customer who has a basic IPMP config in his global zone: > >vnet0 & vnet1 [currently vnet0 has the 'floating' IP] > > In addition he has a zone with ip-type=shared where physical=vnet1 > > When the zone boots the zone interface gets created on vnet0 instead of > vnet1 > > I have verified this behaviour on a test system and can confirm that the > zone interface acts in the same way as the floating IP. i.e. if I run > 'if_mpadm -d vnet0', then the zone's IP fails over to vnet1 > > Unfortunately I can't find any documentation that discusses this > behaviour. Is anybody aware of any documents that explain what we are > seeing? I haven't found any explicit documentation on this topic. But the association, whether you use vnet0 or vnet1, is with the IPMP group. Thus specifying physical=vnet1 clearly doesn't constrain the IP address to always live on vnet1; it moves when there is a failure. Whether its initial placement, even when vnet1 is not failed, is on vnet0 or vnet1 is an implementation matter. Does the initial placement on something different than vnet1 cause a problem? Or is it just confusing? FWIW Once Clearview IPMP integrates this will become more clear since we'll have the IP addresses on an ipmp interface - the failure handling and load spreading will be transparent to the user. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
On Wed, 2008-05-21 at 12:56 -0700, Steve Lawrence wrote: > In the global zone, do you have two ip addresses (one on vnet0, one on vnet1) > or is vnet1 configured as standby? Hi Steve, We have the following global zone config: vnet0: flags=1000843 mtu 1500 index 2 inet 139.149.40.200 netmask ff80 broadcast 139.149.40.255 groupname sldn2680vpgd ether a0:0:8b:95:28:c8 vnet0:1: flags=9040843 mtu 1500 index 2 inet 139.149.40.215 netmask ff80 broadcast 139.149.40.255 vnet1: flags=69040843 mtu 1500 index 3 inet 139.149.40.228 netmask ff80 broadcast 139.149.40.255 groupname sldn2680vpgd ether 0:14:4f:fa:31:5c And then on top of this we end up with an addition vnet0 virtual interfaces per zone. A full explorer is available at /net/cores.uk/export/calls/38083839/explorer Thanks, Lewis ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
On Wed, 2008-05-21 at 15:09 -0700, Erik Nordmark wrote: > Does the initial placement on something different than vnet1 cause a > problem? Or is it just confusing? Hi Erik, In this case it is just causing some confusion but functionality is not impacted. Thanks, Lewis ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
Seems like a feature. vnet1 is in standby, so the active link in the ipmp group (vnet0) is used for the zones. Is the desire to have both interfaces used by zones for additional bandwidth? Do the zones need ipmp as well, or is it ok if a link failure takes out some of the zones? I'm guessing zones should be on ipmp. Perhaps someone on the ldoms team can suggest a configuration. My guess would be to configure two more vnets (2 and 3) on the same underlying network interfaces, and create another ipmp group. Something like this: vnet0 -> e1000g0 vnet1 -> e1000g1 vnet2 -> e1000g0 vnet3 -> e1000g1 ipmp group 1vnet0 -> active vnet1 -> standby ipmp group 2vnet2 -> standby vnet3 -> active Put some zones in group 1 and other zones in group 2. I don't know if this is possible. I don't know how ldoms map vnets to physical interfaces. -Steve L. On Thu, May 22, 2008 at 03:59:07PM +0100, Lewis Thompson wrote: > On Wed, 2008-05-21 at 12:56 -0700, Steve Lawrence wrote: > > In the global zone, do you have two ip addresses (one on vnet0, one on > > vnet1) > > or is vnet1 configured as standby? > > Hi Steve, > > We have the following global zone config: > > vnet0: flags=1000843 mtu 1500 > index 2 > inet 139.149.40.200 netmask ff80 broadcast 139.149.40.255 > groupname sldn2680vpgd > ether a0:0:8b:95:28:c8 > vnet0:1: > flags=9040843 mtu > 1500 index 2 > inet 139.149.40.215 netmask ff80 broadcast 139.149.40.255 > vnet1: > flags=69040843 > mtu 1500 index 3 > inet 139.149.40.228 netmask ff80 broadcast 139.149.40.255 > groupname sldn2680vpgd > ether 0:14:4f:fa:31:5c > > And then on top of this we end up with an addition vnet0 virtual > interfaces per zone. > > A full explorer is available > at /net/cores.uk/export/calls/38083839/explorer > > Thanks, Lewis > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone
If you configure IPMP in a guest domain, it functions in the same way a standalone server would. Just make sure you utilize IP based probing to detect failures. If you configure a zone on the guest domain, it's no different from a standalone server. So if you set the physical to vnet0 and it's part of an IPMP group, then the zone is automatically part of the IPMP group. Meaning, you don't have to do anything special. If your vnet0 connection goes down, your global and non-global zone IP's are moved to the other interface in the IPMP group. FYI, the relationship in LDoms for network interfaces is that the physical NIC is virtualized in the primary domain into a virtual switch (VSW). Your guest domains are connected to that switch through a virtual network interface (VNET). You can have multiple guest domains connected to the VSWs through VNETs. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: Steve Lawrence <[EMAIL PROTECTED]> To: Lewis Thompson <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]; Steve Lawrence <[EMAIL PROTECTED]>; zones-discuss@opensolaris.org Sent: Thursday, May 22, 2008 4:21:42 PM Subject: Re: [zones-discuss] physical= not obeyed when ip-type=shared and physical dev part of IPMP group in global zone Seems like a feature. vnet1 is in standby, so the active link in the ipmp group (vnet0) is used for the zones. Is the desire to have both interfaces used by zones for additional bandwidth? Do the zones need ipmp as well, or is it ok if a link failure takes out some of the zones? I'm guessing zones should be on ipmp. Perhaps someone on the ldoms team can suggest a configuration. My guess would be to configure two more vnets (2 and 3) on the same underlying network interfaces, and create another ipmp group. Something like this: vnet0-> e1000g0 vnet1-> e1000g1 vnet2-> e1000g0 vnet3-> e1000g1 ipmp group 1 vnet0 -> active vnet1 -> standby ipmp group 2 vnet2 -> standby vnet3 -> active Put some zones in group 1 and other zones in group 2. I don't know if this is possible. I don't know how ldoms map vnets to physical interfaces. -Steve L. On Thu, May 22, 2008 at 03:59:07PM +0100, Lewis Thompson wrote: > On Wed, 2008-05-21 at 12:56 -0700, Steve Lawrence wrote: > > In the global zone, do you have two ip addresses (one on vnet0, one on > > vnet1) > > or is vnet1 configured as standby? > > Hi Steve, > > We have the following global zone config: > > vnet0: flags=1000843 mtu 1500 > index 2 > inet 139.149.40.200 netmask ff80 broadcast 139.149.40.255 > groupname sldn2680vpgd > ether a0:0:8b:95:28:c8 > vnet0:1: > flags=9040843 mtu > 1500 index 2 > inet 139.149.40.215 netmask ff80 broadcast 139.149.40.255 > vnet1: > flags=69040843 > mtu 1500 index 3 > inet 139.149.40.228 netmask ff80 broadcast 139.149.40.255 > groupname sldn2680vpgd > ether 0:14:4f:fa:31:5c > > And then on top of this we end up with an addition vnet0 virtual > interfaces per zone. > > A full explorer is available > at /net/cores.uk/export/calls/38083839/explorer > > Thanks, Lewis > > ___ > zones-discuss mailing list > zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
