• HP Moonshot – Lessons Learned and Tips from My First HP Moonshot and Citrix XenDesktop Proof of Concept

    September 8, 2014

    Blog, PVS, XenApp/XenDesktop 7.0 - 7.7

    Recently, I was involved in my first HP Moonshot Proof of Concept (PoC). HP Moonshot is a fairly new technology that can be used to provide hosted desktops to users with Citrix XenDesktop 7.x.  If you are not familiar with Moonshot, I would recommend you watch this excellent video by Dane Young at the Experts 2 Experts Virtualization Conference from May 2014 in Los Angeles.  Citrix and HP also have excellent blogs and articles as well that you can review. In this article, I will show you some of the lessons I learned and some tips for working with Moonshot.

    #1: Physical Delivery is Different

    Forget most of what you know about delivering virtual desktops when working with Moonshot.  Moonshot desktops are physical and require a new way of thinking if you have not worked with delivering streamed images to physical computers before.

    1. Moonshot, with XenDesktop, works with Citrix Provisioning Services (PVS) only.
    2. There is no hypervisor needed for Moonshot desktops.
    3. No Hosting connection is created in Citrix Studio.
    4. The XenDesktop Setup Wizard nor the Streaming VM Wizard in PVS are used.

    These four concepts were definitely new to the Citrix Support people I worked with.  It took quite of bit of patience on my part to instruct them on using PVS and XenDesktop with physical desktops.

    #2: Get Organized; Get a Tool

    I used Devolutions Remote Desktop Manager to make my life easier.  I configured PuTTY sessions for the Moonshot chassis and both Moonshot switches as well as Remote Desktop sessions for many of the nodes and the Citrix and Microsoft infrastructure servers as shown in Figure 1.

    Figure 1
    Figure 1

    This allowed me to have access to all my sessions from a tabbed interface instead of having multiple PuTTY and Remote Desktop sessions scattered over my desktop.

    Before We Get to Items #3, 4 and 5

    Read items 3, 4 and 5 and then I will explain why they are in this article.

    #3: NIC Teaming…Not So Good

    If multiple networks and or VLANs are used and VLAN tagging is used, do not even think of using Broadcom NIC Teaming.  If CTX140338 had mentioned that limitation, we would not have lost days of work trying to get NIC teaming to work.  CTX140338 simply states, “This is an enhancement to facilitate NIC teaming with the latest Broadcom NICs used in HP Moonshot systems.”  If one line had been added that stated “NIC teaming is supported only if a single network with no VLAN tagging is used,” we would have known from the start of the PoC to not use NIC teaming.

    HP and Citrix are working to resolve the VLAN tagging issue so please refer to the latest HP Getting Started Guide for the most up-to-date information.

    More on this in #5 below.

    #4: Don’t Click Cancel

    If you are using just a single network with no VLAN tagging and you want to use NIC teaming, from our experience, the end-user experience will not pass the smell test.  That means, while NIC teaming “works”, the end-user experience leaves much to be desired.  Following the instructions in the HP Converged System 100 for Hosted Desktops Getting Started Guide [18-Oct-2015, the link for this document changes frequently. Just do an Internet search for the title to find the current version of the guide.] the NIC teaming configuration is backed up and then restored after the vDisk is streamed.  What I found out is that during the restore, when the team is created and configured the desktop loses connection to the PVS server.  That means the user will see a message saying the connection to the desktop has been lost and will be retried in 30 seconds.  The user will also be given two choices: Retry or Cancel.  This will be a helpdesk nightmare, especially if the user clicks Cancel. In my testing, I found two things will happen if you let StoreFront and Studio handle the process:

    • After about two minutes, the desktop starts.
    • After about three minutes, you realize nothing has happened, and the user must click the desktop’s icon to get it to launch.

    Bottom line, if you are willing to have users and helpdesk staff hate you, use NIC teaming.  If you are willing to add confusion to the desktop startup process, use NIC teaming.  If you are willing to add two to six minutes to the login and desktop startup process, use NIC teaming.

    HP is working on improving the NIC teaming functionality and vast changes are around the corner.

    #5: NIC Teaming + HP Velocity

    Note: What is HP Velocity? HP Velocity is a software solution that improves the user experience for remote desktop and virtualized applications by addressing common network bottlenecks, such as packet loss, network latency and WiFi congestion.

    If you still want to use NIC teaming AND you are using HP thin clients with HP Velocity installed, do NOT install the HP Velocity driver in your image. HP Velocity and the Broadcom NIC teaming software do not play well together.  When you configure the NIC team, as soon as you click Commit Changes, your image is unrecoverable.  It appears the Velocity driver creates a loop and the Broadcom software cannot recover.  The only way to recover is to reload Windows and rebuild your image.

    As soon as we figured out there was a conflict between the Velocity software and the Broadcom software, HP Labs, the Velocity team and others at HP immediately became involved in getting the issue resolved and a fix was made available.

    The HP Velocity team is aware of the issue and is developing a fix for Moonshot.  The issue revolves around the physical and virtual “bond” building a loopback with the Velocity driver. The HP Velocity team has a fix available now, but it requires booting Windows into Safe Mode.  Since Moonshot is a headless system, there is no way to have Windows boot into Safe Mode. The HP Lab team was able to provide a quick work around by providing a custom installer that corrects the issue (albeit beta code); however, a permanent fix is under development.

    Explaining Items #3, 4 and 5

    Item 3, 4 and 5 exist only because:

    1. The customer wanted to use HP Velocity, and
    2. We did not know HP Velocity and Broadcom NIC teaming had not been tested together by HP, and
    3. We did not know that the PVS Target Device Software did not support how we wanted to use NIC teaming, and
    4. If we had known we couldn’t use NIC teaming, then we could have used HP Velocity and
    5. Not bothered with NIC teaming, and then
    6. Items 3, 4 and 5 would have been nonevents and never written about.

    #6: Persistent ≠ Persistent

    What the Moonshot documentation calls a Persistent Desktop is not what XenDesktop calls a Persistent Desktop.

    With XenDesktop, a Persistent Desktop is one in which a user’s settings and or user installed applications persist between reboots.  A Moonshot Persistent Desktop is where Windows Deployment Services (WDS) installs a full Windows build on every node in the Moonshot chassis.  The Moonshot Persistent Desktops are then managed like regular physical Windows desktops.

    #7: Update Passwords

    One of the first things to be done after the Moonshot chassis is powered on is to update the firmware.   But before you can update the firmware, passwords are needed for the two switches’ Admin and Enable accounts.  After those passwords are set, you can run the new HPSum.bat file to update all the firmware.  HPSum.bat is the new automated way to update Moonshot’s firmware and is included in the Moonshot Component Pack.  If the switch Admin and Enable passwords are not set, the HPSum process will run but at the end will report it was unable to verify the passwords and you will have just lost 1.5 to 5.25 hours of time.  Update the passwords first, next run HPSum.bat and then continue on with the Chassis and Switch configurations.

    It takes roughly five minutes per device to update the firmware.  The minimum number of cartridges in a Moonshot chassis is 15 plus the 2 switches and the Moonshot chassis or 18 devices.  18 * 5 = 90 minutes to update firmware.  30 cartridges plus the 2 switches and the Moonshot chassis (33 * 5 = 165 minutes) will take 2.75 hours to update firmware.  A full chassis will take 5.25 hours.  Those times are based on what we saw.  Your mileage may vary.

    #8: CPU Speed

    Once the firmware has been updated, set the CPU Speed for all nodes.

    set node power off shutdown all
    set node options cpu 1.8 all
    set node power on all

    If you are not sure what CPU speed settings are available, set it to a wrong value and the correct values will be displayed as shown in Figure 2.

    Figure 2
    Figure 2

    #9: Documentation

    The Moonshot documentation does not always match the Moonshot help text.  I found several misstatements that I was able to report to my Citrix contact who then reported them to the HP Moonshot team. I was told that HP would correct the documentation. For example, Powercap mode 1 is not the default.  For us, Mode 0 was the default.    If you have four power supplies, use Powercap Mode 2.

    set chassis powercap mode 2

    #10: Answer Files

    Moonshot requires WDS to install the Windows images onto the nodes.  Windows System Image Manager (SIM) is used to manage the Client and Image unattended answer files provided by HP.  Moonshot is a headless system so there is no video, keyboard or mouse to interact with a full Windows installation process.  The two answer files are necessary but troubleshooting them can be a royal PITA.  I recommend you use a regular Windows VM to do a test install of the customized Moonshot Windows installation.  You do not care if the Windows installation actually runs, you are worried about getting past the point where the answer files are no longer used.  Once Windows is installed to the VM, you know the answer files “should” work and you can proceed to installing Windows onto the first Moonshot node.

    HP recommends using SIM so that any passwords entered are stored encrypted in the answer files.

    A few issue we ran across:

    • The answer files contain several XXXXXXXX lines that need to be replaced with the registered organization and user name.  Even though we had that information entered, the image still had the XXXXXXXX for registered company and user.
    • Even though we had the necessary credentials entered and the checkbox selected in WDS to enable joining the image to the domain, the domain was never joined.
    • The time zone was never set.

    Note: Make sure the Product Key you enter matches the ISO file type.  For example, a Volume License ISO file will not work with an MSDN Product Key.  If the product key does not match the ISO type, the following error (formatted for this article) is given:

    Error message:
    2014-09-05 05:00:00, Info         IBSLIB PublishCriticalError:
    Publishing critical error message
    [Windows could not parse or process the unattend answer file
    for pass [specialize].
    The settings specified in the answer file cannot be applied.
    The error was detected while processing settings for component

    This is an easy error to spot if a regular VM is used to test the answer files.

    #11: Registry Hacks for PVS

    Again, since Moonshot is a headless system, using PVS Maintenance and Test versions will be a royal PITA unless you use the registry setting described in CTX135299 on every PVS server.  It is either that or give every Maintenance and Test user PuTTY access to the Moonshot chassis so they can access the virtual serial port on the node the Maintenance and Test target devices are attached to.

    Rather than have to manually set a registry key on every PVS server, I would prefer an option in the PVS console to make this change.

    #12: No Storms Here

    Two of the main issues XenDesktop architects, engineers and administrators dread with virtual desktops are boot storms and login storms.  Those two items are no longer a concern with Moonshot.  If you did:

    set node power on all

    in a Moonshot chassis with 180 nodes, the power on sequence will not allow all 180 nodes to power on at the same time.  Each Moonshot node has a dedicated quad-core processer, dedicated 8GB of RAM, dedicated 32Gb or 64Gb of SSD local storage and two dedicated network ports.  The one thing every node shares is the BIOS.  I have been given a description of how the power -on sequence works but since that information is proprietary, I cannot share it.  If I get permission, I will update this article with the power-on sequence of events.

    #13: Virtual Serial Port

    In order to view a node’s boot process, Moonshot provides a Virtual Serial Port (VSP). This allows you to see the node’s power on sequence and the initial non-gui Windows boot process. After working for two weeks, the VSP stopped working. Fortunately, the solution is very simple and non-disruptive to any powered on nodes and desktops.

    To view the VSP for a node:

    set node power on <node>
    connect node vsp <node>

    If nothing appears in the VSP, there is a very simple fix.  Enter the following command:

    reset cm

    Note: “cm” is Chassis Manager.

    That command will not affect any cartridges or any nodes currently running.  After a few minutes, you can reconnect to the Moonshot chassis using PuTTY and the VSP is back working.

    #14: Changing the Drive Letter of the Write Cache Drive

    By default, PVS assigns drive D to the write cache drive.  For a Moonshot node, its integrated SSD is disk 0 and, as disk drives do in Windows, has a unique ID.  If there is an application that requires the use of drive D then the write cache drive letter must be changed.  Using a hypervisor, adding an extra drive to a Virtual Machine (VM), creating a template and using that template when running the XenDesktop Setup Wizard makes changing the write cache drive to use a different drive letter fairly easy. No so when using physical devices.

    Since each disk 0 has a unique ID, changing the drive letter of the write cache drive on the node used to create the master image does not make the drive letter change on another node whose disk 0 has its own unique id.  Citrix has an article that explains how to remedy this situation, for the most part.  If only one vDisk is ever created using only one node as the master, then the solution Citrix offers will work.  Their solution will not work if there are multiple vDisks created and or nodes need to boot from multiple vDisks whose master image uses different drive letters for the write-cache drive.

    In Moonshot, if I create a master image using the node C1N1, its disk 0 will have a unique id.  If in that master image I change the write cache drive to letter W, the only way any other node will pick up the use of the letter W for the write cache drive is to change the unique id of its disk 0 to match the unique id from disk 0 in the master node.  Not really a big deal.  I can create a script or process that changes the unique id of disk 0 on say C5N1  to match the unique id of disk 0 from C1N1.  Now what if I need to create another master image, for testing purposes, on C16N1?  C16N1’s disk 0 will have its own unique id.  Now I cannot boot C5N1 from the vDisk created from C16N1 as the unique id that was replaced on disk 0 does not match the disk id of C16N1’s disk 0.  The write cache drive is now back to the default letter D and the application will not work because what should have been drive D is now drive E.

    I don’t know many places that use only one vDisk for every device or every desktop offered to users.  I can see this effecting the ability drag and drop a vDisk on a device collection.  If the new vDisk has a different unique id for disk 0 than what the target device (Moonshot node) is already configured for, any application that requires specific files on the custom drive D will not work.

    Maybe I am making a mountain out of a mole hill but this can be an issue when there are many vDisks and thousands or tens of thousands of nodes/desktops.

    In the end, for this PoC, the customer decided to let PVS handle the D drive and will change their application configuration to use a different drive letter. It proved far easier to change the application than to change a default behavior of PVS.

    You may be wondering what Write Cache option was selected for this PoC. We went with Cache to device RAM with overflow to disk and memory usage was set to 1024MB.

    #15: Arghhh!

    I will end with the two most frustrating things I encountered on this project.

    1.  Dealing with Citrix support!!!!!

    Talk about driving a person to want to drink something stronger than a Ginger Ale!!!  Sheez, dealing with Citrix support on Moonshot/PVS/XenDesktop issues is a lesson in futility because they apparently have not been trained in this area. Example:

    Me: My desktops are not registering.

    Ctx: OK, let’s rerun the XenDesktop Setup Wizard.

    Me: My desktops are physical, there is no hypervisor involved.

    Ctx: But you said you were using VSphere?

    Me: Yes, we are using VSphere for the Citrix infrastructure like the Controller, StoreFront, Director and PVS.

    Ctx: So there is a hypervisor involved!

    Me: For the infrastructure, yes.  For the desktops, no.  We are using HP Moonshot which is physical so there is no hypervisor in use for the desktops.

    Ctx: How can you use a hypervisor for the infrastructure but not for the desktops?  Why would you do that?

    Me: Because XenDesktop and PVS work with physical devices.

    Ctx: Since you do have VSphere, let’s rerun the XenDesktop Setup Wizard.

    Me: You’ve got to be kidding me!!!

    By the way, the issue with my desktops not registering was that in Studio only the machine account SID was showing, not the machine account name.  To resolve the issue, I:

      • Deleted the machines from the Delivery Group and Machine Catalog,
      • Deleted the Machine Accounts from Active Directory (AD) via PVS,
      • Created new Machine Accounts in AD via PVS, and
      • Added the Machines back in to the Machine Catalog and Delivery Group.

    I know I should probably cut Citrix Support some slack since Moonshot is so new, right?  But, PVS and XenDesktop have supported streaming to physical devices for quite a while.  I know PVS has supported streaming to physical devices for a long time.  My first three PVS projects five years ago were using PVS 5.x to stream to physical XenApp servers.  My contention is that Citrix Support should be very familiar with using PVS to stream to physical devices with no hypervisor involved in the process.

     2.  NIC Teaming

    For now, just say no!

    Overall impressions:

    I like Moonshot.  I like the hardware.  I like the concept.  I am amazed that HP can put that many “desktops” in one chassis and not have the chassis melt from all the heat.

    For the use cases where it can be used, I believe it is a cost-effective and energy saving solution.  Having up to 180 desktops with dedicated CPU, memory, storage and networking in under 5U is quite impressive.  HP’s documentation, while not perfect, is very well done.  Their documentation (and videos) assumes a lot of knowledge and understanding the reader may not have.  I am already looking forward to my next Moonshot PoC.

    I want to end by saying thanks to Tony Sanchez (@TonySanchez_CTX), Dane Young (@YoungTech) and Jarian Gibson (@JarianGibson) for going way beyond the call of duty in helping me prepare for this project.  The Citrix and CTP communities rock.

    I also want to thank Technical & Scientific Application, Inc. (TSA) for hiring me to do this PoC.  The people at TSA (@TSAIncorporated) I worked with on this project are some of the smartest and most helpful people I have ever come across.  Greg Tinker (@TinkerTwinsTech), William Howard and Harrison Travis are just freakishly smart.  Landon Fokens, well he’s a sales person.  What can I say except he sure paid for a lot of lunches? 🙂

    I am not allowed to mention the customer but S.B. (@SBoggs), you are a superstar.  Thanks for putting up with all the stress and the NIC teaming nightmares, I mean, issues.



    , , ,

    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster

    40 Responses to “HP Moonshot – Lessons Learned and Tips from My First HP Moonshot and Citrix XenDesktop Proof of Concept”

    1. JP Raj Says:

      Hi Carl,

      I am currently working on Moonshot\PVS POC. PVS and TFTP are configured on same server . Netscaler is used to load balance TFTP.
      Normal vm’s (ESXi) are able to boot using NS LB but moonshot server is not able to boot from NS LB. “No Network device is available”
      Same server is able to boot directly from PVS.



      • Carl Webster Says:

        My apologies for the delayed response. I am neither a NetScaler nor networking person so I am unable to answer your question.

        I did send your query to a friend who also works with Moonshot and also does NetScaler and networking. His response:

        Could be any number of things…I’d need to know how the Moonshot switches are configured (L2 or L3..any VLANS in play…any IP helpers/forwarders..)
        Are the PVS servers and ESX VMs on the same virtual switch on the ESX host? How is the ESX host connected to the moonshot chassis? Where is the Netscaler? a VPX on the ESX host, or a physical box somewhere else?




    2. Frank Murphy Says:

      Carl, have you ever used SCCM to try to lay down the golden image on the moonshot node? We just started our POC, however we are facing issues getting an OS on our m700 cartridge’s. Were able to pxe boot to sccm and lay down the image, however when it reboots we get “non system disk or disk error.” Any advice would be appreciated. Thanks.


      • Carl Webster Says:

        I have not, I have only used WDS.



        • Frank Murphy Says:

          Thanks Carl. We reverted back to using WDS instead of SCCM and had much better luck with the imaging process. We are successfully running a PVS based image now on our Moonshot nodes. Performance so far looks to be very good. However we are seeing one issue with our video display. Im curious if you came across it at all. When using any browser within your pvs xendesktop session on moonshot, do you get any pixelation, tiling, quality issues when moving the windows around? For example, minimizing your chrome or firefox window, and than re-opening it. This appears to be our main hangup so far with the POC. Thanks for any info.


          • Carl Webster Says:

            None of the PoCs I have done have used web apps or extensive use of any browser. I am doing another PoC next week. I will check it out and let you know.



      • Satish Kumar Says:

        Hi You can use MRCA (Moonshot remote control Administration) for Moonshot setup , WDS is good but faced challenges with lot of bcd edit and answer files, another thing I tried SCCM also but corrupted my master image for 710 server WIN2012,

        MRCA is cool all u need is link it with Cartridge/Node and You can get screen of HP ILO and isnatll OS


    3. Bruce Lautenschlager Says:

      Carl –

      Great article – not much real world experience being documented publicly for Moonshot yet. I was curious about your thoughts on storage. What were you using for storage on your various deployments? I know it’s an older article, so I assume it might have been the HP SL4540? Either way, if you were going to deploy one today what type of storage solution might you prefer? (You don’t have to mention brands – just the technology – like JBODs with SAS Expander switches, etc.)



      • Carl Webster Says:

        The projects I have done in the USA have been for HP Platinum partners so they have been using HP’s 3Par storage. The project I did in the Middle East, I do not remember what they used for storage.

        I am not a storage guy so storage hardware specifics are not something I pay attention to. The projects I have done have just used the existing customer solutions for folder redirection, profiles and user experience management. I am agnostic when it comes to what customers use. I do have my personal preferences but I am hired by the partner and represent the partner so I never give my opinion of what I believe the customer should do unless the partner who hired me asks for my opinion. I do not want to recommend a solution the partner may not like or use or may be a competing offering to what the partner sells.




    4. Brian Langston Says:

      Love your review of this. I’m testing a Moonshot chassis right now and at first the headless systems bothered me, but now I kind of like it. My biggest gripe/complaint was why the 4x40GB uplink per switch. Does that not seem like massive overkill? I would think that 4x10GB would have been more than sufficient. I put 500+ users on a fully loaded C700 with 2 2x10GB VPCs and have no issues. Each Moonshot is less than half that, but has 160GB possible throughput on each switch? I guess 40GB just must be cheap now so they do it. It just makes things a bit more tedious using a 4x10GB breakout cable or SFP adapter. I work for a VERY large company and we don’t have any 40GB connections to hosts, only on uplinks, and even the 10GB connections aren’t saturated. I just don’t see the point of 40GB yet.

      I really hope we get this – I would love to take the hypervisor out of the picture. I also have changed my views with regards to HA somewhat – unless it’s a developer or someone that needs a persistent desktop, moonshot seems like a better solution. So a cartridge dies – log back in and get a new desktop and back to work. Heck, for our existing environments and many use cases, I think xenmotion, HA is overkill. If I use local storage for the write cache, again, no need for SAN storage at all. If a host dies, ok – log back in. We use physical servers for Xenapp right now, so we don’t have an HA setup for that, and even with VM’d Xenapp, you still impact users if the VM has an issue. I see moonshot really taking off, pun intended!


      • Carl Webster Says:

        I am sure HP had their reason for providing those ports. I have asked my super genius Moonshot friend and fellow CTP Dane Young to respond to your concerns.



    5. Rui Lopes Says:

      Hi Carl,
      Nice article,

      what about delivering XenApp image insted a windows 7?
      i’m thinking about a hosted shared VDI or just publishing apps to users.

      what are your thoughts about it? have already tested it?



    6. Dylan Ogle Says:

      Hi Carl

      Thanks for a great article. I’m curious to know how you have tackled High Availability from a Citrix perspective, as well as user profiles in terms of user data. In the case of a DR situation and computing between two data centers, what would you recommend for the underlying Citrix infrastructure (Store Front servers, XenApp, Desktop Delivery Controllers, PVS, storage from a NAS perspective for high availability?

      Could you also advise whether your PVS is a physical server or virtual machine? My apologies for all of the questions but your insight would be most appreciated.


      • Carl Webster Says:

        I have done both physical and virtual PVS servers with Moonshot. Have no idea why it would matter. No different from any other XD/XA project.
        I am a fan a local to the PVS server for vDisk storage.

        If you will be using Moonshot in production, you would need multiple StoreFront, Controller, Director and PVS servers. No different from any other XD/XA project.

        User profiles same thing. Manage user profiles the way you would for any other XA/XD project.

        The XD/XA side is the same regardless of the technology used for endpoint devices.

        If you need further help for your Moonshot project, you can contact me Webster@carlwebster.com or fellow CTP and Moonshot advocate Dane Young youngtech@gmail.com




    7. Nate Says:

      How do you perform a reverse image with Moonshot? Say there is a new PVS version and you need to update the Target Device Driver.


    8. Dan Says:

      Carl, I haven’t read through all the comments here, but I wanted to let you know, you do NOT need PVS to publish a Moonshot Desktop with XenDesktop. You can publish it as a static desktop. (Do not use PC Remote though).


      • Carl Webster Says:

        You are correct. You can use whatever you want to push the OS image onto the Moonshot node and use whatever you want to stream an OS image to any node you want. BUT, if you want or need support from HP and or Citrix, you will need to use their documented, tested and verified processes.



    9. BW Says:

      Carl- I’m curious what kind of performance you saw in your POC. We are on the waiting list for a demo chassis from HP to do some performance benchmarking but it could be some time before we see it. We are currently have around 2000 users running XenDesktop 5.6 on Cisco UCS B230-based (Intel Xeon E7-2870 2.4ghz) servers on VMWare ESXi 5.0, but we have users who are requesting beefier desktops for heavy Excel calculations. I know on paper the Xeon should handle this faster but in our experience when the ESX server is under full load, CPU performance drops heavily. Does CPU performance on the Moonshot really rival a physical workstation in your experience, was it closer to VDI or somewhere in the middle?


      • Carl Webster Says:

        I can only give you the comments from the testers on the three Moonshot projects I have been involved in. They all say the Moonshot delivered desktop is faster than their local physical desktop. Since each user gets four dedicated cores running at 1.8Ghz, 8GB dedicated ram, dedicated GPU and dedicated SSD storage – contention between users for host resources just does not exist with Moonshot.

        Email me and I can put you in contact with the HP Platinum partner I am working with and maybe they can work with HP to get you a PoC worked out.



    10. Ahmad Mousa Says:

      I just finished from installing the whole HDI environment using moonshot 1500, m700 cartridges, XenDesktop and PVS using standard image type.

      I was trying to make two pools one for persistence users which they can save data and the other for non-persistence users.

      for non-persistence users there were no issues and the desktop refresh back after reboot.
      but for persistence pool using a machine group with static desktop experience, the user data had been deleted after reboot !!

      if that is the case then
      wt is the difference between static and random machine group as a user experience ?
      how I can deploy a persistence users to be able to save their data by using moonshot, XenDesktop and PVS?


      • Carl Webster Says:

        Static means the user gets the same desktop (Moonshot node) every time. That is what you need if you want to use persistence.

        I have done a mix of random and static but persistence only works with static.



    11. Thorsten Says:

      The 8GB of DDR3 memory per SOC on the m700 is a bit tight for some users.
      There are ECC SO-DIMMs with 16GB (per single module) from Intelligent Memory (part# IMM2G72D3LSOD8AG) which do work fine on the m700 Cartridge!
      Unfortunately there is no official HP approval for them, yet, but these memory modules are in production and available.


    12. Peers Says:


      would you like to do a production deployment?



    13. Oscar Says:

      Hello Carl!

      thanks for sharing info

      I have already installed a cartridge with windows 7 successfully, but I can’t do the same with Windows 8.1.I’m not sure if it is supported, I haven’t found any documentation about…



    14. Manish Chacko Says:

      Hi Carl,
      So $900 for each desktop. How about Citrix licensing and hardware for PVS? As I understand it, Moonshot solution will not work with Citrix VDI license and requires Enterprise ($225) or Platinum ($350) edition. So, that bumps it up to $1125 or $1250 per desktop plus the cost of PVS hardware. Plus, since the desktops are not virtualized, you lose all the benefits of desktop virtualization (resource sharing, faster provisioning, disaster recovery/vMotion,etc,etc) in the first place. 180 users in 5 U is a lot less than what traditional VDI can support which is roughly 200 users per 2U or 500 users per 5U. Last, but certainly not least, Moonshot will still require you to have/purchase endpoints. Maybe I don’t understand this solution fully and there may be corner use cases where this is a good choice, but I can’t imagine customers choosing Moonshot over traditional desktop virtualization or VDI based on cost or simplicity of administration.
      I’d like to hear your thoughts.


      • Carl Webster Says:

        Don’t you have to have endpoints regardless of the solution?

        Moonshot m700 cartridge is for specific use cases where users need 8GB dedicated RAM, dedicated quad-core processor, dedicated GPU and dedicated local SSD storage. How many of those types of users can you get in your 2U server?

        If I do the math for 180 users, that would require your 2U server to have (just for the users) 1,440GB of RAM, 720 1.8GHz cores, 180 dedicated GPUs and 5,760GB or 11,520GB of integrated SSD storage. Does such a server exist in 2U or 4U? Oh that’s right , it does – HP Moonshot. 🙂

        Most people virtualize PVS so no dedicated hardware required for PVS.

        I quoted full-blown retail for a fully loaded and configured Moonshot chassis. I don’t know of any enterprise that pays full retail. Do you? Full retail is the only price I know.

        Also, since Moonshot is physical, there is no Microsoft VDA tax.




        • Manish Chacko Says:

          Moonshot m700 cartridge is for specific use cases where users need 8GB dedicated RAM, dedicated quad-core processor, dedicated GPU and dedicated local SSD storage. How many of those types of users can you get in your 2U server?
          Fair enough, that’s a lot of hardware but it’s definitely not mainstream requirements-maybe that addresses less than 5% of workloads?
          Most people virtualize PVS so no dedicated hardware required for PVS.
          Fair enough-but that virtualized PVS server has to live somewhere and it’s not on the Moonshot chassis-my point was that Moonshot is not a complete solution-additional hardware is needed.
          I quoted full-blown retail for a fully loaded and configured Moonshot chassis. I don’t know of any enterprise that pays full retail. Do you? Full retail is the only price I know.
          Again, good point-but retail is the only fair way to compare prices as discounts vary from customer and quantity purchased. I don’t know of any VDI customer paying full retail price either and so this point is moot.
          Also, since Moonshot is physical, there is no Microsoft VDA tax
          Couple of points on this-if you don’t have VDA or MS Companion license, you cannot let users BYOD. Second, if a non-windows end-point accesses a physical desktop, I’m sure Microsoft will require you to have some kind of license. For the life of me, I cannot imagine what it is-I’d be curious to hear from production Moonshot users as to what Microsoft licensing they had to purchase. FYI, the “HP Converged System 100 for Hosted Desktops Getting Started Guide” has this to say:
          “Microsoft licensing information for HP ConvergedSystem 100
          Microsoft requires licenses for the HP CovergedSystem 100 cartridges and client devices such as PC, laptop, thin client, and so on. Microsoft volume licensing provides the Win7 Enterprise OS licensing.
          • If client devices are covered under Microsoft Software Assurance, then you do not need anything else
          (includes VDA rights).
          • If client devices are not covered under Microsoft Software Assurance, obtain a VDA license for each


    15. Jeff Lindholm Says:


      I find this article quite interesting because I am coming from a different angle. I have been running physical desktops on PVS in production for about 4 years now (AutoCAD workstations), so I am well versed on how to do that.

      I am disappointed to see that moonshot basically does not have a good integrated gui-capable KVM or iLO solution built into it to at least get the gold image going, oh well.

      The reason I am even interested in this is that we also use XenApp and XenDesktop for other workloads, and the one in particular that I want to run is GoToMeeting for WebEx, which basically blow chunks on traditional XenApp or XenDesktop. So I am thinking throw moonshot in there and use vm hosted apps (or whatever they are calling it now) to solve that particular use case without having to resort to either redirection or just running it from the real desktops.

      The only other really whacky thing I thinking here is, what would happen if you threw XenClient Enterprise into this mix? Do the cartridges even support virtualization features? If that was supported, then that would solve the gold image issue, because you would then have a hyper-visor, and you would be able to edit your gold image even elsewhere entirely if you wanted.

      Also, if these cartridges are powerful enough, what if you could get 2-3 desktops on one? Then could you go past the 180 physical.

      Don’t know at this point if GoToMeeting also has a problem on XenClient Enterprise, making this idea moot.



      • Carl Webster Says:


        I have no insider knowledge of what HP plans for Moonshot. All I have is my own first-hand experience in dealing with the various teams involved in Moonshot at HP, Citrix, Velocity and Broadcom. I can almost guarantee you that HP listens very closely to what happens with Moonshot in the field. I am sure that any and every pain point and issue are felt in Houston where the HP Moonshot team and labs are based.

        All I can say is I agree with you. It will be nice when (if) HP releases an updated Moonshot that has an integrated GUI capable KVM, VSP or iLO solution. It will also be nice to see HP and Moonshot support running XenApp 7.x server based hosted desktops on the m700 or later cartridges.

        Just doing some WAG based math, if I have 180 quad-core based nodes with 8GB ram and I can get 15 XenApp 7.x users per node, that would be 2,700 users in just over 4U. Bump up the processors, increase the RAM to say 32GB and the SSD storage to 128GB per node and you could probably get 32 XenApp 7.x users per node or 5,760 users per Moonshot chassis.

        Again, I have NO knowledge of ANY future plans for Moonshot. Everything I just replied to you with could be just a big pile of crap.

        Currently, XenClient is not supported on the m700 cartridge.

        Looks like we both will just have to sit back, wait and see what HP does with Moonshot.




    16. Michael Janssen Says:

      I like the Moonshot technology a lot, because if you already have a Client Management solution for your notebooks and PCs, the easiest step into VDI (or HDI like HP calls it), would be to just deploy OS, Patch & Apps like you used to, install the VDA at the end and broker them as Remote PCs. No need for PVS at all…


    17. Andrew Wood Says:

      That is an informative and usful read Carl, thanks for sharing.

      Mind I was sightly bemused at the #6 – XenDesktop, a Persistent Desktop is one in which a user’s settings and or user installed applications persist between reboots.. which is *can be* a full Windows build managed like regular physical Windows desktops. IMO Citrix have long tried to craft something that manages a full persistent desktop and only really succeed in something messy.

      I think HP’s concept of persistent is better – interested to hear your thoughts.


      • Carl Webster Says:

        If you think HP’s is better then you would not need PVS or XenDesktop. Just use WDS, System Center and App-V and you should be good to go. 🙂



    18. Paul Says:

      Carl, the question I struggle with is it worth it? Maybe yes for a small scale deployment? Moonshot is really expensive from a per-desktop perspective. The dedicated resources are great but it brings me back to the old Blade PC days. Sure you can do it but at what cost :). Thanks for a very good article.


      • Carl Webster Says:

        I think it is worth it. Up to 180 desktops with 8GB RAM, 4-core CPU, up to 64GB SSD, AMD graphics and dual NICs, four 40Gb uplink ports and up to four redundant power supplies all in under 5U is not bad. Divide all that up by 180 desktops and I bet you will find the cost per desktop is going to be just over $900 using full retail pricing for Moonshot.

        No hypervisor cost, no SAN needed, 5 million hour MTBF, excellent support from HP and you can use the most excellent and highly scalable Citrix PVS product.




        • David Caddick Says:

          Hi Carl,

          Is that $900 per User for HW only?
          This seems more like Workstation class performance/price?



          • Carl Webster Says:

            Yes, that is just based on the full retail price I was given for a fully loaded with every possible option Moonshot chassis with M700 cartridges. I doubt any enterprise will pay full retail for anything.



    Leave a Reply