Physical Reservation not possible until you create a virtual Fabric Group??

[Michael_Rudloff]

For the sake of some version testing I have installed a vCAC 6.1 infrastructure, and all I want to test is the deployment of physical blades on UCS manager.

It seems that "Reservations" won't show up until I create a dummy Fabric group, which is really just needed for virtual resources.

Is that by design ?

[stvkpln]

That sounds right, but the question is.. why would you have reservations for physical assets? I don't believe you would / do.

[Michael_Rudloff]

stvkpln wrote:

That sounds right, but the question is.. why would you have reservations for physical assets? I don't believe you would / do.

When connecting to a physical endpoint you need a reservation to determine the physical resources to be used. When creating an endpoint to a UCS Manager for example, the endpoint will see all the blades in the chassis no matter which ones are in use. A reservation is required to configure the blades available for vCAC deployment in UCSM. In fact, you can't even request a Blueprint unless you got a reservation configured.

But for that you don't need a Fabric group, but it seems to require one to even display the reservation option

[stvkpln]

Only thing I could think of is that you need to create an endpoint for UCSM... Maybe that's the missing piece?

[Michael_Rudloff]

stvkpln wrote:

Only thing I could think of is that you need to create an endpoint for UCSM... Maybe that's the missing piece?

I think you misunderstand my issue. Endpoint is created obviously . Let me try again.

1. Plain install

2. Tenant created

3. AD configured

4. Users configured

5. Endpoint added

6. Data collection successful and inventory visible in Endpoint settings (all chassis and blades)

7. No option to add a reservation or reservation policy under 'Infrastructure' settings

8. Create a fake fabric group

9. Option to create a reservation and policy becomes available

Fabric group is for virtual resources which don't apply here. You could argue that it isn't a big deal but you will receive gigs of errors in logs as the agent is not configured / missing. That is also because you don't need an agent as the endpoint is going through the DEM.

[stvkpln]

I get what you'er saying, but based on what I just found from reviewing the vCAC documentation, Fabric Groups are not a concept limited to only virtual/cloud assets, as you indicated. They are used to define compute entities that can be carved up as provisionable boundaries for a group of administrators. Not the same thing.

Please review this section of the vCAC Documentation and let me know if that helps. You may need to navigate through a few of the pages to work out the steps, but most/all of what you need should be in there. Lots of other good info regarding how physical reservations work, as well.

[Michael_Rudloff]

stvkpln wrote:

I get what you'er saying, but based on what I just found from reviewing the vCAC documentation, Fabric Groups are not a concept limited to only virtual/cloud assets, as you indicated. They are used to define compute entities that can be carved up as provisionable boundaries for a group of administrators. Not the same thing.

Please review this section of the vCAC Documentation and let me know if that helps. You may need to navigate through a few of the pages to work out the steps, but most/all of what you need should be in there. Lots of other good info regarding how physical reservations work, as well.

Thanks but I know the documentation and when you drill down you will notice yourself that Fabric Groups are NOT related to Physical Endpoints.

Have a look here

vCloud Automation Center Documentation Center

"An IaaS administrator can organize virtualization compute resources and cloud endpoints into fabric groups by type and intent."

And

vCloud Automation Center Documentation

"Physical machines do not belong to fabric groups"

So again, a Fabric Group should NOT be a requirement when creating Physical Endpoints. We are talking two different concepts here.

If you want to know more - maybe have a look at the differences how virtual and physical endpoints work. A virtual endpoint connects to an agent and resources are being presented in fabric groups, which you then carve up. In the physical world the resources are presented to the Endpoint via the DEM, not via an agent.

In case of the Cisco UCS Manager, once you connected to the management interface, as mentioned, you see all avialable resources not in Fabric Groups, but in the Endpoint itself

You then create a Reservation where you decide, which of these blades can be used for the deployment via vCAC

That is all you need to do - you can still create reservation policies to link a Blueprint to a certain reservation. This is especially necessary when your UCS chassis have blades of different physical configurations and you only one got Server Pool / Service Profile Template in UCS configured. Anyway, this is going a bit offtopic now, but basically the question remains

Why do I need to configure a "fake" fabric group if I don't have a vSphere infrastructure because as I say - as soon as you create a fabric group, even though you don't need one, you end up with TONS of errors in your logs because there is no virtual Endpoint

I appreciate that it is unlikely that people have vCAC in their environment without actually having a virtual infrastructure and it isn't a big deal as this is just a test, but I am curious if I am just missing something obvious.