15
votes

Long story short - I need to use networking between projects to have separate billing for them.

I'd like to reach all the VMs in different projects from a single point that I will use for provisioning systems (let's call it coordinator node).

It looks like VPC network peering is a perfect solution to this. But unfortunately one of the existing networks is "legacy". Here's what google docs state about legacy networks.

About legacy networks Note: Legacy networks are not recommended. Many newer GCP features are not supported in legacy networks.

OK, naturally the question arises: how do you migrate out of legacy network? Documentation does not address this topic. Is it not possible?

I have a bunch of VMs, and I'd be able to shutdown them one by one:

  1. shutdown
  2. change something
  3. restart

unfortunately it does not seem possible to change network even when VM is down?

EDIT: it has been suggested to recreate VMs keeping the same disks. I would still need a way to bridge legacy network with new VPC network to make migration fluent. Any thoughts on how to do that using GCE toolset?

1
Shared VPC is another option for separating billing for projects. cloud.google.com/vpc/docs/shared-vpcDagang
Legacy networks in a host project are not shared with service projects. The shared VPC networks in a host project must be VPC networks.Julius Žaromskis
I'm in a similar situation and I'm curious what your migration path ultimately looked like. Would you be able to post an update or answer that describes it?Sammitch
Sorry to disappoint, but I haven't done the migration. Seems too much trouble for what it's worth to me. I was contemplating using some kind of VPN ipsec tunnel and bringing VMs one by one, as suggested by Kluyg below.Julius Žaromskis
Use the VM's external IP during migration (+firewall rule). After migration, re-attach the VM NIC to the VPC network (requires VM shutdown) and revert to using internal name/IP.rustyx

1 Answers

3
votes

One possible solution - for each VM in the legacy network:

  1. Get VM parameters (API get method)
  2. Delete VM without deleting PD (persistent disk)
  3. Create VM in the new VPC network using parameters from step 1 (and existing persistent disk)

This way stop-change-start is not so different from delete-recreate-with-changes. It's possible to write a script to fully automate this (migration of a whole network). I wouldn't be surprised if someone already did that.

UDPATE

https://github.com/googleinterns/vm-network-migration tool automates the above process, plus it supports migration of a whole Instance Group or Load Balancer, etc. Check it out.