Regarding this: It is a real need but this does not seem possible in LPAR/PowerVM environment.
It is possible to do this with AIX, I don't believe PowerVM or LPM allow you to make this type of change.
If you don't need to do this with an LPM, you probably don't need the EtherChannel setup.
Just move the IP address as per step 3 (only 1 adapter), then steps 5, 6 and 7.
1 - Add new VLANs to the VIOS if required.
2 - Add a new vEth to the LPAR with the same VLAN as currently in use.
3 - Add two new vEth to the LPAR with the new VLAN - We need two so we can undo the EtherChannel once migration is done.
4 - Create an EtherChannel device with the current VLAN's new vEth on primary, and one target new VLAN vEth on backup.
mkdev -c adapter -s pseudo -t ibm_ech -a adapter_names='ent4' -a backup_adapter='ent6' -a netaddr={gateway IP for subnet}
5 - Move the base vEth adapters IP address to the EtherChannel vEth.
This is the clever part for AIX, you can move an IP address from one adapter to another with a very minor network blip.
ifconfig en0 inet {IP_Address} transfer en8 mtu 1500 netmask 255.255.255.128
6 - Clean up the current original adapters IP settings. E.g. for en0 in step 5.
chdev -l en0 -a netaddr= -a netmask= -a state=detach
7 - Add the IP address, netmask to the new Etherchannel settings.
chdev -l en8 -a netaddr={IP_Address} -a netmask=255.255.255.128 -a state=up -P
8 - Perform the LPM if required. Noting once you are on target frame the primary will fail and the backup will take over (if VLANs are trunked on SEA).
9 - Move the IP address from the EtherChannel to the new vEth you created in step 2 - the one you didn't use for the EtherChannel.
10 - Remove the IP settings from EtherChannel.
11 - Add IP settings to the new vEth you move the IP to in step 9.
12 - Clean up all the no longer required EtherChannel and associated vEth and Update LPAR profile with
mksyscfg -m frame -r prof -o save -p LPAR -n normal --force
------------------------------
Stephen Diwell
------------------------------
Original Message:
Sent: Wed March 05, 2025 08:10 AM
From: Sylvain
Subject: LPM & using different vSwitch on target ?
Hi,
Dynamically changing the VLAN ID (PVID) is not only possible but often necessary for flexible network architecture. Modern virtualization platforms and network switches support on-the-fly VLAN retagging, allowing seamless reconfiguration of network segmentation without service interruption, enabling administrators to quickly adapt network configurations to changing infrastructure or security requirements.
It is a real need but this does not seem possible in LPAR/PowerVM environment
Original Message:
Sent: 3/5/2025 7:28:00 AM
From: José Pina Coelho
Subject: RE: LPM & using different vSwitch on target ?
A possible use case is that some VLAN was originally presented untagged on the switch port, and the SEAs configured to bridge untagged frames for an incorrect VLAN number.
As usual, nobody is authorized to stop the whole thing to correct it, but if we have an option to remap the VLAN ID during an LPM, we could fix it incrementally without stopping anything.
------------------------------
José Pina Coelho
IT Specialist at Kyndryl
Original Message:
Sent: Tue March 04, 2025 01:30 AM
From: Tommi Sihvo
Subject: LPM & using different vSwitch on target ?
Hi,
Thanks Bartlomiej,
Tbh, so much time has passed on this, that I can't even recall the use case for which I asking this for :D
Most probably it was tackled somehow at least. :)
Br,
tommi
------------------------------
Tommi Sihvo, Lead Service Architect
Tietoevry Tech Services
email tommi.sihvo@tietoevry.com mobile +358 (0)40 5180 Finland
Original Message:
Sent: Mon March 03, 2025 04:46 AM
From: Bartlomiej Grabowski
Subject: LPM & using different vSwitch on target ?
Hi Tommi,
I have never searched a command to change VLAN ID, because it does not make sense.
VLAN ID is adding a tagged_id of the VLAN to a TCP frame, it is hard to imagine, that the same LAN switch handles the same packets from the same VLAN with different tag_ids.
------------------------------
Bartlomiej Grabowski
IBM Champion - Platinum Redbook Author and Principal System Specialist
Original Message:
Sent: Thu December 02, 2021 03:00 AM
From: Tommi Sihvo
Subject: LPM & using different vSwitch on target ?
Hi,
One more question related to this...From CLI it is possible to give new vSwitch...but how about the VLAN ID?
Is it possible to change VLAN ID as well, or does it need to remain the same as in source frame?
Br,
tommi
------------------------------
Tommi Sihvo, Lead Service Architect
TietoEVRY, Compute Services
email tommi.sihvo@tietoevry.com mobile +358 (0)40 5180 Finland
Original Message:
Sent: Mon November 08, 2021 03:40 AM
From: Abderahim ABBAS
Subject: LPM & using different vSwitch on target ?
Hi
I hope that you have a migration strategy :)
You have HMC command to it dynamically without downtime :
hscroot@hmcXXX:~> migrlpar -o m -m CPU-FRMXXXX -t CPU-FRMXXXY -p LPAR1 -i 'shared_proc_pool_name=shp_app,"vswitch_mappings=180/VS_P8/VS_LAN_PROD_CMN,3358/VS_P8/VS_LAN_PROD_CMN"'
Where :
CPU-FRMXXXX : frame source
CPU-FRMXXXY: target frame
shp_app: shared pool name, same on target frame
LPAR1 : partition name
vswitch_mappings: on frame source, my partition LPAR1 VLAN's 180/3358 configured on Vswitch VS_P8, and on target frame i changed Vswitch name to VS_LAN_PROD_CMN. no change of subnet configuration.
About this point :
live-partition-mobility-lpm-move-pvidvlan-one-vswitch-another-vswitch-across-dual-hmc-using-hmc-cli-command
Hope that help you.
Abderahim.
------------------------------
Abderahim ABBAS
Original Message:
Sent: Fri November 05, 2021 08:31 AM
From: Tommi Sihvo
Subject: LPM & using different vSwitch on target ?
Hello,
Quick and stupid q; Can you force LPM somehow to use different vSwitch & VLAN on destination frame compared to source?
E.g on source VM has vSwitch Happy, VLAN ID 123; and on destination it would be Weekend, VLAN 234?
(Actual L2 level network would remain identical (IP address, subnet, gw, mask etc))
Or does one need to "fake" the old switch & VLAN info on destination; do offline LPM; modify VM profile to be correct & then re-activate VM.
Br,
tommi
------------------------------
Tommi Sihvo, Lead Service Architect
TietoEVRY, Compute Services
email tommi.sihvo@tieto.com mobile +358 (0)40 5180 Finland
------------------------------