I think my original mini-lab did this, I had mistakenly joined these hosts to the big lab pool, found out is was wrong and detached them to make a mini-lab pool. There were some oddities when I did this, but I just worked past them and created their own pool and did my warm migrations. Wish I had taken better notes of this when I did it.

I wiped and rebuilt my mini-lab now, so no going back.

Again, the question is why after detaching, the "Label" column shows three exactly the same names? I can rename them, but that's not the point.

I'm asking if the same "Labels" can be somehow explained...

It looks like after detaching slave host from the pool it inherits master name as a label - that doesn't look correct.

@DustinB No, no... look at the "Label" column.

The question is - why after detaching hosts from pool, they all have "Label" the same as pool master?

All of these hosts are in different pools, the individual host name is moot once joined to a pool (at least it appears to be).

Are you unable to rename the hosts to something else?

The question is - why after detaching hosts from pool, they all have "Label" the same as pool master?

That is expected behavior

Next thing is that every time I hit "Detach" on any host, it jumps into "Settings -> Servers" with the same name as the host which currently is an master.

So right now I have on my "Servers" list below situation.

All three hosts have the same "Label".

When I add them back to the pool everything goes back to normal.

I'm able to rename those without any issue but is it some kind of a bug or expected feature?

But... after bringing back the old master (without reinstallation or anything) XOA sees it as master HOWEVER xe pool-list sees as a master different host.

So it looks like after bringing master down, HA election of new one takes place however XOA is not aware of it.

Is there a way to point XOA to new master?

To check which host is the new master I've logged via SSH to one of the slaves and did below.

[05:40 phx01xcp03 ~]# xe pool-list
uuid ( RO)                : 03e8733b-fbd0-61c9-3850-353bfd9e3149
          name-label ( RW): Pool_01
    name-description ( RW):
              master ( RO): a65dcfcb-8a60-4aa8-a467-2351140f80d4
          default-SR ( RW): <not in database>

Which shows UUID of newly elected master.

[05:52 phx01xcp03 ~]# xe host-list uuid=a65dcfcb-8a60-4aa8-a467-2351140f80d4
uuid ( RO)                : a65dcfcb-8a60-4aa8-a467-2351140f80d4
          name-label ( RW): hidden_label
    name-description ( RW): Default install

Not sure why default-SR has "<not in database>" status.

Bringing this back up because I'm thinking of retiring old servers in exchange for new mini-PC.

Looking around in XO, I don't see anywhere to click to promote a server in a pool to controller (master), am I missing something?

My plan would be to join all new mini-pc to the existing pool, migrate VMs to these new servers, then take controller (master) onto one of the mini-pc. After that I would remove the older servers from the pool and shut them down.

Is the proper way to use the above command, or go to the local console and just force promote one of the new mini-pc to be the new controller?

[edit] found it, been a while since I've set up a pool. Click where the arrow is and you get choices on which server in the pool you want to control things.

it's pretty simple because XAPI is replicated to all pool member while the master is running (but all other members got it in read only). If the master dies, then promote another member and you are done.

Yes, but why you would do that if the old master is down? I mean, you won't be able to add your new host to the existing pool if the previous master is down

The OP may have been vague, nothing is down in my environment (just a random thought of "What if?").

If my pool master died for whatever reason, how would I get control over the pool again if I were able to build a replacement server?

SSH into another server in the pool and run

xe pool-emergency-transition-to-master

?

It's easy:

• add your new host into your existing pool (it will adapt the CPU features automatically, anyway)
• promote the new host as the pool master
• that's it!

What if the original pool master is down or non-functioning?

• add your new host into your existing pool (it will adapt the CPU features automatically, anyway)
• promote the new host as the pool master
• that's it!