GCP Deployment challenges

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L1 Bithead

GCP Deployment challenges

I thought I'd share with you a few of the Google Cloud Platform VM-Series deployment challenges I ran into recently.

 

First off, read the documentation carefully, this is a new product and the docs are being updated regularly, not to mention that GCP and their documentation is also constantly undergoing tweaks.  

One thing that wasn't immediately clear is that the number of NICs is directly delated to the VM CPU core count.  You might need to select a custom CPU core count (even count only) if you need more than the basic 3 NICs in your project.

You should be aware that you should not reduce the VM CPU core count below 4 as you would not have enough NICs and the deployment will fail.

One thing to point out though is that you'll notice in the GUI that there are seven ethernet interfaces regardless of the number of NICs you attach to the project when you deploy it, combined with the management interface, brings the total to eight, but only the first n-NICs are usable depending on the number of CPU cores you selected.

 

Before you rush off and deploy an instance, you will need to create a bunch of VPC Networks with subnets inside each one.  The documentation covers this fairly well.  You'll typically want External IPs on the Management and External  VPCs that will be attached to those respective interfaces.

You need to be aware that once the VPC Network is attached to a virtual NIC, it cannot be changed.  Plan ahead!

 

The next issue relates to non-default CPU core count.  There appears to be an issue with the VM-Series Image template or deployment scripts in the Cloud Launcher.  If you use a non-default CPU core count, your public key login won't work until you STOP / START the VM after it has completed the first boot up.

Wait until you can access the GUI login page on the management interface, then stop the VM, and start it again.  Once the GUI login page is accessible you can SSH to the instance with your public key.

 

Speaking of the public key, there is some confusion in the documentation about this, and the correct format is:

admin:ssh-rsa keystring

For example:

admin:ssh-rsa AAAAB3NzaC9yc2E3H...FpYfsXKz==

 

After a number of false starts, and some great help from Palo Alto's support team, I managed to get a VM instance running, and it is working as expected.

 

I have one outstanding issue, it is the VM Monitoring which doesn't appear to be working...yet.

Highlighted
Cyber Elite

Hello,

Just curious if you used the vm-300 that is in Launcher or if you just deployed your own CE with a BYOL?

 

Regards,

Highlighted
L1 Bithead

For now it is a VM-300 BYOL trial license, but will become a VM-100 BYOL once it goes into production.

Highlighted
Cyber Elite

Thank you for the info. I would be interested to know how it goes when going from a vm-300 to a vm-100 license. I know its just capacity more than anything but still curious.

Highlighted
L0 Member

I want to thank you and throw you a virtual hug as I was beyond a point of frustration on getting this operational and your tips below were solid gold in getting it going.

 

Thank you so much again.  You were a lifesaver.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!