During the installation of Oracle VM Server, you choose the VLAN option to configure your network, so when you discover your server with Oracle VM Manager you found the VLAN group "NETWORK-ADDRESS-vng". You can't delete this group if it is related to an Oracle VM Server.
You can create many VLAN Segmant associated to the VALN Group and you can create many VLAN Group.
For more Information, look at this URL.
I hope this can help you
you can manage many servers with one Oracle VM Manager, so Oracle VM Manager has one management network that's mean one vlan-group. so you cannot move to a separate VLAN Group.
If you have two network cards on your Oracle VM Manager, so you can access to Server-Production with management network (first valn-group) and you can access to Server-Non-Production with the other one.
I hope this can help you
Thank you for you reply. I am sorry if I did not explain my problem very well. Let me try again:
I have 2 server pools: Production pool and non-Production pool. All the servers have only 2 interfaces forming a bond.
Production servers use VLAN 1000,2501,2502,2503.
Non-Production servers use VLAN 1000,3501,3502,3502.
VLAN1000 is the common management VLAN for both pools.
I want to have 2 VLAN groups:
- Production VLAN group with only 4 segments: 1000,2501,2502,2503
- Non Production VLAN group with only 4 segments: 1000,3501,3502,3503
My colleague has made 1 VLAN group with all 7 segments: 1000,2501,2502,2503,3501,3502,3503.
I cannot "move" the server interfaces from his VLAN group to my VLAN group. Even if I delete a server and re-discover, it always goes back to the VLAN group that my colleague created.
I just went through this very same issue.
You've got two options as I see it, one supported and one that likely isn't.
The 1st, is to move your management network to an interface separate from the rest of your data VLANs. I'm in the process of rebuilding all my OVM servers to do this because it appears that having the cluster heartbeat on the same VLAN as VMs trying to PXE boot is causing cluster communication issues. This is of course the supported solution, you would have a common management network that spanned your production and non production servers, but could define a data network and VLAN group unique to each environment.
The 2nd, is to delete the servers from OVM Manager, edit a few network configuration files by hand and rediscover the server. I assume this wouldn't be supported if you run into issues, but this is how I originally built my environment. Because of other issues though, I'm rebuilding with option 1. Log into the OVM Server and change to the /etc/sysconfig/network-scripts directory. The files you would be looking for are:
meta-bond0 - Contains the name of the VLAN group discovered into OVM Manager. Rename this to something not already in use.
meta-bond0.1000 - Contains the name of the bridge associated with the VLAN and the network name. You'll need to change the bridge and network name to something unused.
ifcfg-<bridge> - Need to change the DEVICE= field in this file to match the bridge you chose in the above file and rename the file appropriately.
ifcfg-bond0.1000 - Need to change the BRIDGE= field in this file to match the bridge above.
Reboot and rediscover the server and it will create the VLAN group and network you defined in the meta files. You'll need to do this for each server in that environment. You'll be able to edit the VLAN group for these servers separately from the VLAN group for your other environment and only add the VLANs you need to each.
I haven't run into any problems since I implemented it and I don't see any reason why there would be, but technically it's an unsupported solution, since you're not really supposed to be editing those files manually.
If you're not concerned about support, then I think it's a far better solution than having all of the VLANs in one big group, since you end up plumbing a bunch of invalid interfaces on the servers that aren't connected to all of the VLANs. Keep in mind if you add more servers later, you'll need to discover them, delete them, edit those files and rediscover. Those meta files aren't created until the server is discovered for the 1st time.
The issue is that OVM Manager doesn't allow you to reconfigure the management interface, likely because there'd be no way to undo any mistakes if the OVM Manager loses connectivity to the server. Personally, I'd prefer they implement a delayed reconfiguration mode for the management interface that allows you to make changes and then initiate a reboot. As an added option, it could create a backout script that you could execute via command line on the server if the changes failed.