Yes, in theory it sounds good, but the IPv6 overlap check seems to block everything. I think our best way forward is to move the network to ROOT and ensure all free IPs are allocated in the db so that other users cannot use the network.
Thanks for thinking along Wei, Daan and Pearl! On Fri, Apr 26, 2024 at 5:27 PM Wei ZHOU <ustcweiz...@gmail.com> wrote: > 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 > > > > > > > > > > > > > >
