none
Problems with PXE boot on Hyper-V Guests

    Question

  • Problem

     

    I am encountering a strange scenario when using System Center Configuration Manager R2. If I create a new virtual machine with Hyper-V (Generation 1) I am unable to get the virtual machine to load the boot wim file.

     

    The PXE process looks normal and the Virtual Machines starts to load the boot wim file but only loads around 3-10% before it fails. It then exits with the following message: “Windows Failed to start. A recent hardware change or software change might be the cause”

     

    Status: 0xc0000001

    Info: A required device isn’t connected or can’t be accessed.   

     

    However there is NO PROBLEM if I use a physical machine or a Generation 2 Hyper-V virtual machine with the same boot image and task sequence.

      Client Setup

    Gen1-VM is setup like this:

    Memory: 4096MB (dynamic memory disabled)  CPU: 2 Virtual Processors Legacy Network Adapter IDE DISK

     

    Gen2-VM is setup like this:

    Memory: 4096MB (dynamic memory disabled)  CPU: 2 Virtual Processors Network Adapter SCSI DISK

     

    Server Setup

    A Single standalone primary site site running Server 2012 R2 with 4 Virtual CPU’s and 16GB of RAM (dynamic memory disabled). The database is located on another virtual machine but on the same physical host (test vm’s are also running on the same hyper-v host). The server is using HTTP traffic and multicast has been disabled. The WDS feature has been automatically installed by SCCM. The “RamDiskTFTPBlockSize” reg key is set to the default 1024 (400 HEX). UAC and Windows Firewall has been disabled while testing.

     

    Log Files

    I noticed that when the WDS service starts it give me some errors in the SMSPXE log. The same error is reported for all my boot images. I attempted to redistribute the boot images but without success. Other than the errors below, I don’t see many errors.

     

    Adding OSL00002.3         SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::GetFileProperties failed; 0x80070003       SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::CopyFileW failed; 0x80070003     SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::ExpandContentDefinitionItems failed; 0x80070003           SMSPXE               29.09.2014 18:38:10                3696 (0x0E70)

    CContentDefinition::Expand failed; 0x80070003             SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    Adding OSL00005.6         SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::GetFileProperties failed; 0x80070003       SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::CopyFileW failed; 0x80070003     SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::ExpandContentDefinitionItems failed; 0x80070003           SMSPXE               29.09.2014 18:38:10                3696 (0x0E70)

    CContentDefinition::Expand failed; 0x80070003             SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    Adding OSL00024.3         SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::GetFileProperties failed; 0x80070003       SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::CopyFileW failed; 0x80070003     SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

    CContentDefinition::ExpandContentDefinitionItems failed; 0x80070003           SMSPXE               29.09.2014 18:38:10                3696 (0x0E70)

    CContentDefinition::Expand failed; 0x80070003             SMSPXE               29.09.2014 18:38:10        3696 (0x0E70)

     

     


    Monday, September 29, 2014 5:39 PM

Answers

  • OK looks like ive sorted this one out.

    The TFTP block size makes no difference what so ever in my case.  The solution is to remove NIC Teaming. By removing one of the NICs form the Hyper-V team and creating a new Virtual Switch using only that NIC the boot image loads just fine. I was also able to raise the TFTP block size to 8192 and still working fine :) If i try to create a new VM on another server that is using NIC Teaming the problem returns. Could be i configured my NIC Teaming or swich wrong but at least the root cause was found. 

    • Marked as answer by eppis Monday, October 13, 2014 7:37 PM
    Monday, October 13, 2014 7:37 PM

All replies

  • Here is the screenshot when the client fails to load the boot wim file.

    Monday, September 29, 2014 5:41 PM
  • Are you using the x64 boot image?

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, September 29, 2014 5:41 PM
  • yes sorry forgot to mention that.. the x64 boot image is being used. 
    Monday, September 29, 2014 5:44 PM
  • For those unfortunate souls like you and me: http://mwesterink.wordpress.com/2013/12/17/

    In short, the problem can be related to an incorrect network packet size. You can open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP, add a DWORD key RamDiskTFTPBlockSize and set its value to something like 1400. Then restart the WDS and SMS_EXECUTIVE services, and you're done.

    I bumped into this problem when I was testing my new SCCM server with an ESXi 5.1 virtual machine with VMXNET 3 network adapter (recommended by VMWare instead of traditional E100B). I replaced the VMXNET 3 virtual card with an E100B one, and the problem diappeared.


    Evgeniy Lotosh
    MCSE: Server infractructire, MCSE: Messaging

    Monday, October 6, 2014 10:18 AM
  • Thanks for your tip Evgeniy,

    Unfortunately it does not look a like the Reg key has any big effect for me. With your recommended setting of 1456 it did not improve at all, so i attempted to lower it even further. With a setting of 512 (might be too low) the problem still persists. Increasing the value lowers the time physical clients need to load the image which is expected when increasing the TFTP block size. I will do some more testing using a variety of virtual and physical hardware to see if i can find a trend. Il also try to enable the TFTP trace as you described in your post. Il follow up here once i do more testing.

    Any other troubleshooting tips? 

    Monday, October 6, 2014 7:30 PM
  • OK looks like ive sorted this one out.

    The TFTP block size makes no difference what so ever in my case.  The solution is to remove NIC Teaming. By removing one of the NICs form the Hyper-V team and creating a new Virtual Switch using only that NIC the boot image loads just fine. I was also able to raise the TFTP block size to 8192 and still working fine :) If i try to create a new VM on another server that is using NIC Teaming the problem returns. Could be i configured my NIC Teaming or swich wrong but at least the root cause was found. 

    • Marked as answer by eppis Monday, October 13, 2014 7:37 PM
    Monday, October 13, 2014 7:37 PM
  • It seems NIC teaming was configured really incorrectly in this case. Different switches require different configuration with specific settings on the Windows Server side. Sometimes incorrect configurations work when network traffic is low but start behaving funny when it increases. The reason behind this is Windows hosts sending back answers to its peers via different physical links, and the switch doesn't expect it and drops "incorrect" frames.

    You can find detailed description of different teaming modes here: http://www.aidanfinn.com/?p=14004

    If you use LACP, be sure to set up port channel on Cisco switches or LACP trunk on HP switches. Otherwise you might want to use the Switch Independent mode.


    Evgeniy Lotosh
    MCSE: Server infractructire, MCSE: Messaging


    Tuesday, October 14, 2014 4:04 AM