Hi Pearl and Ruben, I think the main issue is that both networks (same gateway/cidr but under different accounts) should work. Pearl's idea is good, we can add some steps as below
- backup the database - remove a Free IP from `user_ip_address` table - create a shared network with startip/endip = FreeIP, and same vlan, choose skipping the vlan check - get the id of the new vlan from `vlan` table, update the ip4_range of new vlan to same - get the id of network from `networks` table - If VR is needed, update `vlan_db_id` and `network_id` of a Free IP to the new network/vlan so the new network has 2 IPs (1 for VR, 1 for VM) - assign Vm to the new account by API, the Free IP will be assigned to the VM - update `vlan_db_id` and `network_id` of the old vm IP to the new network/vlan - update vm IP to the old vm IP - start the VM I have not tested it yet. Kind regards, Wei On Fri, Apr 26, 2024 at 5:06 PM Pearl d'Silva <pearl.dsi...@shapeblue.com> wrote: > > I did not hit the issue with overlapping IP ranges as the network in the > destination domain / account was initially created with a different vlan and > then they were updated (or swapped) with the VLAN in the source domain. > However, I did not test with IPv6. > > > > > > > ________________________________ > From: Ruben Bosch <ruben.bo...@cldin.eu> > Sent: April 26, 2024 10:58 AM > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > Subject: Re: Shared guest network assigned to multiple domains > > Hi Pearl, > > Thanks for the suggestion. Yes, assignVirtualMachine is an option, but in > this case the used network is not accessible by the destination > domain/account. Creating the same network twice also doesn't seem like an > option due to NetUtils.ipRangesOverlap. It also seems to not be a > possibility to create the same network without filling in the start/end IPs > for IPv4, because then another error is triggered for the IPv6 range > overlapping "The IPv6 range with tag: 1000 already has IPs that overlap > with the new range." (tested on 4.18.1). The VXLAN ID in this case remains > the same and the VLAN ID overlap check is disabled. > > Regards, > > Ruben Bosch > > On Fri, Apr 26, 2024 at 4:21 PM Pearl d'Silva <pearl.dsi...@shapeblue.com> > wrote: > > > Hi Ruben, > > > > Have you tried the 'Assign Instance to Another Account' > > (assignVirtualMachine API) operation on the stopped VMs. This would help in > > moving the VM(s) from one domain/account to another. I did a small test to > > see if we could preserve the IP and it seemed to work but I may be wrong in > > my understanding. This was my setup: > > > > VM1 in domain /ROOT/dom1 deployed in shared network shdom1 with vlan: 700 > > with CIDR: 10.70.70.1/24 > > > > Created another domain /ROOT/dom2 and created a shared network shdom2 in > > this domain with vlan, say: 701 with CIDR: 10.70.70.1/24 > > > > swap the vlans via DB updated: > > update networks set broadcast_uri = "vlan://701" where id = <id_of_shdom1>; > > update networks set broadcast_uri = "vlan://700" where id = <id_of_shdom2>; > > update vlan set vlan_id = 701 where id =<id_of_shdom1> ; > > update vlan set vlan_id = 700 where id = <id_of_shdom2>; > > > > Stop the VM(s) in /ROOT/dom1 domain that need to be moved, and then use > > the Assign Instance to another Account to move VM to the destination domain > > and account. > > > > Regards, > > Pearl > > > > > > > > ________________________________ > > From: Ruben Bosch <ruben.bo...@cldin.eu> > > Sent: April 26, 2024 9:26 AM > > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > > Subject: Re: Shared guest network assigned to multiple domains > > > > Wei, the use cases may vary. In some cases it will be moved completely to a > > different domain+account, in other cases not. > > > > On Fri, Apr 26, 2024 at 2:48 PM Wei ZHOU <ustcweiz...@gmail.com> wrote: > > > > > Hi Ruben, > > > > > > Will you move all VMs on the network to another account, or just some > > > of the VMs ? > > > > > > -Wei > > > > > > On Fri, Apr 26, 2024 at 2:44 PM Ruben Bosch <ruben.bo...@cldin.eu> > > wrote: > > > > > > > > Thanks Daan :-) Hope there are others with some ideas as well! > > > > > > > > On Fri, Apr 26, 2024 at 2:42 PM Daan Hoogland <daan.hoogl...@gmail.com > > > > > > > wrote: > > > > > > > > > ok, from what I know now I have exhausted my clues. Hope you get your > > > > > migration done expediently. > > > > > > > > > > On Fri, Apr 26, 2024 at 2:29 PM Ruben Bosch <ruben.bo...@cldin.eu> > > > wrote: > > > > > > > > > > > > Hmm, that might be possible. However we would like to automate as > > > much as > > > > > > possible. Changing existing IPs to unused ones is not an option, > > no. > > > > > > > > > > > > On Fri, Apr 26, 2024 at 2:25 PM Daan Hoogland < > > > daan.hoogl...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > ok, and you probably can't redistribute the IPs in the domain or > > > > > > > define the order of migration to be in line with the range? > > > > > > > > > > > > > > On Fri, Apr 26, 2024 at 2:01 PM Ruben Bosch < > > ruben.bo...@cldin.eu> > > > > > wrote: > > > > > > > > > > > > > > > > The target domain already exists with VMs running in it > > > > > > > > > > > > > > > > On Fri, Apr 26, 2024 at 1:46 PM Daan Hoogland < > > > > > daan.hoogl...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > so probably a stupoid suggestion, but why ot rename the > > domain > > > > > then? > > > > > > > > > > > > > > > > > > On Fri, Apr 26, 2024 at 1:04 PM Ruben Bosch < > > > ruben.bo...@cldin.eu> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Daan, cases may vary. For our first migration in the end > > > all > > > > > VMs > > > > > > > will > > > > > > > > > > move to the other domain. > > > > > > > > > > > > > > > > > > > > On Fri, Apr 26, 2024 at 12:32 PM Daan Hoogland < > > > > > > > daan.hoogl...@gmail.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Ruben, do you need to move domainA completely to domainB > > > or do > > > > > you > > > > > > > > > > > need to move *some* VMs from it? > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 26, 2024 at 11:00 AM Ruben Bosch < > > > > > ruben.bo...@cldin.eu > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > We're looking into the following. We are using advanced > > > > > > > networking > > > > > > > > > on ACS > > > > > > > > > > > > 4.16.1 (upgrading soon to 4.18.1). We have a guest > > > network > > > > > that > > > > > > > is > > > > > > > > > > > assigned > > > > > > > > > > > > to a specific domain A (ROOT/foo/domainA). Now we will > > > need > > > > > to > > > > > > > move > > > > > > > > > VMs > > > > > > > > > > > > from domain A to domain B (ROOT/bar/domainB) while > > > > > preserving IP > > > > > > > > > > > addresses. > > > > > > > > > > > > We are exploring our options on how to make this a > > > seamless > > > > > > > > > transition. > > > > > > > > > > > We > > > > > > > > > > > > have found that: > > > > > > > > > > > > > > > > > > > > > > > > - we cannot add the network with the same parameters > > > again, > > > > > as it > > > > > > > > > fails > > > > > > > > > > > on > > > > > > > > > > > > IP address start/end overlap check > > > > > > > > > > > > - we cannot add the extra domain in the > > > "domain_network_ref" > > > > > > > table > > > > > > > > > as it > > > > > > > > > > > > yields no result > > > > > > > > > > > > - we can assign the domain to ROOT and ensure no other > > > users > > > > > can > > > > > > > > > claim > > > > > > > > > > > IPs > > > > > > > > > > > > by updating "state" in "user_ip_address" > > > > > > > > > > > > > > > > > > > > > > > > Are there any other options available that we can think > > > of? > > > > > I'm > > > > > > > > > looking > > > > > > > > > > > > forward to your input. > > > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > > > Ruben Bosch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Daan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Daan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Daan > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Daan > > > > > > > > > >
