Quantcast
Channel: VMware Communities : Discussion List - VMware Fusion® (for Mac)
Viewing all articles
Browse latest Browse all 12061

VMWare EFI Netboot problem

$
0
0

I've been trying for a while now to netboot into an OS 10.8 guest and have been running into a problem with compatibility between my netboot server (a Dell KACE K2000) and VMWare Fusion Pro (also applies to ESXi 5.5). For some reason, I jsutcan't get VM's to netboot at all. It seems to be something to do with the VMWare EFI not quite broadcasting the correct information when it goes to netboot. Physical macines will netboot just fine. In my efforts to troubleshoot the issue, I ended up setting up the VM to make sure the DHCP packet it sends out are as close as possible to what a physical machine sends out. Here are my results so far:

 

This first packet is from a WORKING PHYSICAL machine. It is the last packet sent out before it receives a proper response from the K2000 containing bootfile name, root path etc...

 

No.     Time           Source                Destination           Protocol Length Info

    196 18.139846000   10.4.40.180           255.255.255.255       DHCP     357    DHCP Inform   - Transaction ID 0x0

 

 

Frame 196: 357 bytes on wire (2856 bits), 357 bytes captured (2856 bits) on interface 0

Ethernet II, Src: Apple_03:2f:0d (40:6c:8f:03:2f:0d), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 10.4.40.180 (10.4.40.180), Dst: 255.255.255.255 (255.255.255.255)

User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)

Bootstrap Protocol

    Message type: Boot Request (1)

    Hardware type: Ethernet (0x01)

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x00000000

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

    Client IP address: 10.4.40.180 (10.4.40.180)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 0.0.0.0 (0.0.0.0)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Client hardware address padding: 00000000000000000000

    Server host name not given

    Boot file name not given

    Magic cookie: DHCP

    Option: (43) Vendor-Specific Information

        Length: 19

    Option: (53) DHCP Message Type

        Length: 1

        DHCP: Inform (8)

    Option: (55) Parameter Request List

        Length: 5

        Parameter Request List Item: (1) Subnet Mask

        Parameter Request List Item: (3) Router

        Parameter Request List Item: (67) Bootfile name

        Parameter Request List Item: (43) Vendor-Specific Information

        Parameter Request List Item: (60) Vendor class identifier

    Option: (57) Maximum DHCP Message Size

        Length: 2

        Maximum DHCP Message Size: 1500

    Option: (60) Vendor class identifier

        Length: 28

        Vendor class identifier: AAPLBSDPC/i386/MacBookPro8,1

    Option: (61) Client identifier

        Length: 7

        Hardware type: Ethernet (0x01)

        Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Option: (255) End

        Option End: 255

 

 

The Response from the K2000:

 

No.     Time           Source                Destination           Protocol Length Info

    197 18.140539000   10.4.40.57            10.4.40.180           DHCP     618    DHCP ACK      - Transaction ID 0x0

 

 

Frame 197: 618 bytes on wire (4944 bits), 618 bytes captured (4944 bits) on interface 0

Ethernet II, Src: Vmware_b8:00:46 (00:50:56:b8:00:46), Dst: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

Internet Protocol Version 4, Src: 10.4.40.57 (10.4.40.57), Dst: 10.4.40.180 (10.4.40.180)

User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)

Bootstrap Protocol

    Message type: Boot Reply (2)

    Hardware type: Ethernet (0x01)

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x00000000

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

    Client IP address: 10.4.40.180 (10.4.40.180)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 10.4.40.57 (10.4.40.57)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Client hardware address padding: 00000000000000000000

    Server host name: 10.4.40.57

    Boot file name: netbootintel/i386/booter

    Magic cookie: DHCP

    Option: (53) DHCP Message Type

        Length: 1

        DHCP: ACK (5)

    Option: (60) Vendor class identifier

        Length: 9

        Vendor class identifier: AAPLBSDPC

    Option: (54) DHCP Server Identifier

        Length: 4

        DHCP Server Identifier: 10.4.40.57 (10.4.40.57)

    Option: (43) Vendor-Specific Information

        Length: 12

    Option: (17) Root Path

        Length: 72

        Root Path: nfs:10.4.40.57:/kbox/datastore/current/tftpboot/netbootintel:netboot.dmg

    Option: (255) End

        Option End: 255

    Padding

 

As you can see, the K2000 responds with a Bootfile Name and Option 17.

 

Now, for the VM. You'll notice it reports the same Model and MAC Address as the physical machine, to rule out any wonky filtering being done by the k2000:

 

No.     Time           Source                Destination           Protocol Length Info

   4455 198.409015000  10.4.40.180           255.255.255.255       DHCP     341    DHCP Inform   - Transaction ID 0xf3d34dfa

 

 

Frame 4455: 341 bytes on wire (2728 bits), 341 bytes captured (2728 bits) on interface 0

Ethernet II, Src: Apple_03:2f:0d (40:6c:8f:03:2f:0d), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 10.4.40.180 (10.4.40.180), Dst: 255.255.255.255 (255.255.255.255)

User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)

Bootstrap Protocol

    Message type: Boot Request (1)

    Hardware type: Ethernet (0x01)

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0xf3d34dfa

    Seconds elapsed: 4

    Bootp flags: 0x8000 (Broadcast)

        1... .... .... .... = Broadcast flag: Broadcast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 10.4.40.180 (10.4.40.180)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 0.0.0.0 (0.0.0.0)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Client hardware address padding: 00000000000000000000

    Server host name not given

    Boot file name not given

    Magic cookie: DHCP

    Option: (43) Vendor-Specific Information

        Length: 7

    Option: (53) DHCP Message Type

        Length: 1

        DHCP: Inform (8)

    Option: (55) Parameter Request List

        Length: 5

        Parameter Request List Item: (1) Subnet Mask

        Parameter Request List Item: (3) Router

        Parameter Request List Item: (67) Bootfile name

        Parameter Request List Item: (43) Vendor-Specific Information

        Parameter Request List Item: (60) Vendor class identifier

    Option: (60) Vendor class identifier

        Length: 28

        Vendor class identifier: AAPLBSDPC/i386/MacBookPro8,1

    Option: (61) Client identifier

        Length: 7

        Hardware type: Ethernet (0x01)

        Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Option: (255) End

        Option End: 255

 

As far as I can tell there are only 2 differences between these packets:

1. Option 43 (Vendor Specific Information) is still only Length 7 coming from the VM. Earlier packets from earlier in the netboot process are length 7 from the physical machine, but you'll see that the packet that I listed has Length 19. It has a fair amount more information.

2. The Physical machine specifies 57 DHCP Maximum Size. I don't think this one matters as much, it's 1500 which matches the network's MTU.

 

Here's how the K2000 responds to the VM:

 

No.     Time           Source                Destination           Protocol Length Info

   4456 198.409714000  10.4.40.57            10.4.40.180           DHCP     618    DHCP ACK      - Transaction ID 0xf3d34dfa

 

 

Frame 4456: 618 bytes on wire (4944 bits), 618 bytes captured (4944 bits) on interface 0

Ethernet II, Src: Vmware_b8:00:46 (00:50:56:b8:00:46), Dst: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

Internet Protocol Version 4, Src: 10.4.40.57 (10.4.40.57), Dst: 10.4.40.180 (10.4.40.180)

User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)

Bootstrap Protocol

    Message type: Boot Reply (2)

    Hardware type: Ethernet (0x01)

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0xf3d34dfa

    Seconds elapsed: 0

    Bootp flags: 0x8000 (Broadcast)

        1... .... .... .... = Broadcast flag: Broadcast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 10.4.40.180 (10.4.40.180)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 10.4.40.57 (10.4.40.57)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: Apple_03:2f:0d (40:6c:8f:03:2f:0d)

    Client hardware address padding: 00000000000000000000

    Server host name not given

    Boot file name not given

    Magic cookie: DHCP

    Option: (53) DHCP Message Type

        Length: 1

        DHCP: ACK (5)

    Option: (60) Vendor class identifier

        Length: 9

        Vendor class identifier: AAPLBSDPC

    Option: (54) DHCP Server Identifier

        Length: 4

        DHCP Server Identifier: 10.4.40.57 (10.4.40.57)

    Option: (43) Vendor-Specific Information

        Length: 47

    Option: (255) End

        Option End: 255

    Padding

 

It just responds the same way it does to all DHCP, because the last packet the VM sends out before timing out is the same as all the previous. For some reason, it's not getting past the LIST stage of the netboot process. I'm not 100% sure if the bug is really on the VMWare side or the K2000 side. Probably both honestly. All I get out of the log on the k2000 is "BSDP LIST from 10.4.40.180:68 (MacBookPro8,1/i386)". The odd thing is, looking back in the logs I see the OCCASIONAL entry in the log indicating that the VM actually made it to the SELECT stage (BSDP SELECT from 10.4.40.196:622 (VMware7,1/i386)). That's from before I changed the Hardware ID to match a known-good machine. But it's random, few and far between. No actual change from the VM in those cases.

 

Some other pertinent info about the environment: The k2000 does both PXE and Netboot. We need to have both available onthe same network, so DHCP options are set up for PXE. I have also confirmed that windows VM's will netboot just fine. Perhaps the VMWare EFI doesn't like the presence of both on the same network?


Viewing all articles
Browse latest Browse all 12061

Trending Articles