Creating additional vnet in service domain on same switch does nothing for you. 
If you want separation make a new vsw on another physical card. You aren't 
buying any additional clarity by doing so. You do defeat the point of 
consolidation which is resource sharing. This is assuming both physical NIC are 
same subnet. 
For resiliency you would give both to both guests so they can survive physical 
network outage (one would hope these go to separate physical switches). 

The basic consolidation procedure is make one vnet in service domain per 
physical card and give that to each guest. Using vnet0  consistently for same 
network makes it easier to use tools like jumpstart profiles 

You can get additional resiliency with split IO and 2 service domains each with 
1 NIC (more specifically one per PCI bus in Ldoms 1.3 though if you have 4 pci 
bus put 2 per svc dom. 
). .  

----- Original Message -----
From: [email protected] 
<[email protected]>
To: [email protected] <[email protected]>
Sent: Tue Nov 30 08:01:09 2010
Subject: Re: [ldoms-discuss] Correct usage of vnet in LDOMs / Oracle VM Server 
for Sparc 2.0

Hi Terence,

Thank you for your answer but could you clarify some more- specifically: 

If I create vnet0 on guest1 and vnet0 on guest2, am I creating one vnet and 
attaching it to two domains or am I creating two separate vnets with the same 
name that needs to be taken in the context of whichever domain I'm working 
with? 

If I'm creating one vnet, then maybe I'm creating dependencies between domains 
which I might be better off not creating?

If I'm creating two vnets with the same name but require the context of the 
domain they're connected to, then maybe I'm opening the door to human error and 
I'd be better off naming them something more unique?

Thanks,
Yonah
-- 
This message posted from opensolaris.org
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss

Reply via email to