Do you mind sharing your hardware config? I was able to get it to boot finally, however I am stuck at an issue when trying to login.Made an account to reply to this.
Yes, I have PANOS as my primary firewall (as a vm). I have 2 double NICs PCI passthrough'd, 1 for management, 1 for WAN, and 1 for LAN.
It was a heck of a time to set up.
In the processor setup, try changing type to "host" and see if that helps..Do you mind sharing your hardware config? I was able to get it to boot finally, however I am stuck at an issue when trying to login.
View attachment 45189
View attachment 45190
So it looks like there are two requirements here. One is the host cpu change and the other is at least 2 interfaces, which makes sense becasue the first interface is dedicated to management and you need at least one for the data plane.Came across this and got my Palo to work. The fix was adding the right hardware.
Adding host CPU did not resolve my issue, but adding enough network interfaces did. I'm using Palo Alto 11 (KVM) and encountered errors like unable to communicate to sysd on the login screen.
Followed this guide,
https://gist.github.com/cdot65/595e09f7d599024d65a56ee1cfc3abb2
The only difference in my configuration was enabling hotplugging resources and adding network interfaces (I'm assuming the missing interfaces was the problem).
Final config looks like this:
Hardware
RAM: 6 GB
CPU: 2 Cores (host)
BIOS: SeaBIOS
Display: Default
Machine: q35
SCSI Controller: VirtIO SCSI
Network Device (net0): virtio, bridge=vmbr0
Network Device (net1): virtio, bridge=vmbr0
Network Device (net2): virtio, bridge=vmbr0
Network Device (net3): virtio, bridge=vmbr0
Serial Port (serial0): socket
Some Relevant Options
OS Type: Linux
Hotplug: Disk, Network, USB, Memory, CPU
ACPI Support: Yes
KVM hardware virtualization: Yes
qm importdisk 113 xyz.vmdk ceph-pool1
qm importdisk 113 xyz_1.vmdk ceph-pool1
There is absolutely NO requirement to have 10 nic's on the VM. You can have "up to" 10 nics on the VM to use, but you do not have to..My Palo is successfully migrated from ESXi to Proxmox. I was always aware of need to have 10 NICs on the guest, but the addition of serial was the key.
View attachment 47795
I used sftp to copy over all the vmdk files and imported using qm as shown below.
qm importdisk 113 xyz.vmdk ceph-pool1 qm importdisk 113 xyz_1.vmdk ceph-pool1
Once tested, I shutdown on Proxmox and brought up the Palo ESXi in order to deactivate the license on the old host. Then shutdown Palo on ESXi for the last time and started up on Proxmox, where the final license activation on the new platform was then completed.
Totally understand and agree. I think I used the wrong words more than anything. In the past, when I have built VMs I found that adding and deleting vNICs can create some out of order situations and more difficult to identify (need to check MAC). So that's why I add 10 before that first power up.There is absolutely NO requirement to have 10 nic's on the VM. You can have "up to" 10 nics on the VM to use, but you do not have to..
I am very successfully running with two nic's configured without any issue. You do have to have a minimum of two. One for management and one for data to pass through the firewall.
Serial port is also not required, but is great to have to see what is going on during boot.
I just banged my head against this for a couple hours on PAN-OS 10.1.12. Changing the machine version from "Latest" to 8.0 also resolved for me.I've been fighting this same issue tonight -- Palo VM hanging at PA-HDF login.
This is with PA-VM-KVM 10.1.6-h6 (and 10.1.6).
My Proxmox cluster is running 8.1.3
The funny part is, PA VM 10.2.7 installs and runs just fine with default options.
I noticed right before the PA-HDF prompt, there was (very briefly) an error on the console, and I had to screen-cap the console to see it.
It was an error in the "vm_license_check" script, saying: option -m require argument
-m is "memory size", so it's clear Palo was having trouble collecting the RAM size to size the VM appropriately.
After a lot of playing around, I found that the "machine" type was the trick.
The default (i440fx) and q35 didn't work.
But setting q35 to version <=8.0 works for me.
The "ostype", NICs, CPU and SCSI type don't seem to make a difference.
There was also no need to boot to maintenance mode and re-install the OS once I had a working configuration.
This is a repeatable successful deployment for me on 8.1.3:
qm create 453 --name pavm3 --memory 4608 --cores 2 --ostype l26 --machine pc-q35-8.0 --serial0 socket \
--net0 model=virtio,bridge=vmbr0,tag=100
qm disk import 453 /mnt/pve/ISO/PaloAlto/PA-VM-KVM-10.1.6-h6.qcow2 VMProx1 --format qcow2
qm set 453 --scsihw virtio-scsi-single --virtio0 VMProx1:453/vm-453-disk-0.qcow2 --boot order=virtio0
I hope that helps someone!