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 > > > > > > >
