Category Archives: vCloud
It seems I keep running into things throwing my in a loop and I am sure someone else out there in the VMTN worlds knows that I am talking about. I love vCloud, I enjoy the product, but man some things are still pretty vague although it continue to grow more and more each day I definitely want to do my part to help contribute. So I will make this a short and quick post.
Well take a peek at this VMware Knowledgebase and it will describe in detail the issue I ran into:
“Upgrading vCloud Director 1.5 with an Oracle database to vCloud Director 1.5.1 fails with the error: CALL create_missing_index()”
Although it is hard to say why this is a bug in the database or duplicated entries most oracle DBA’s can knock it out fairly easy. However let me explain to you how this happens and provide some further insight on how to resolve it without having to guess.
Now I want to point out that someone forgot to use the call-management tool (which you can find here) but one would think that this is mostly a database issue because it’s referencing a duplicate table entry. Also this seems to happen with updating vCloud from 1.5 to 1.5.1.
If you run into this issue you need to do the following:
- Restore the Database
- Run the KB Fix of the following:
“DELETE FROM object_condition WHERE object_id IN (SELECT object_id FROM object_condition GROUP BY object_id, object_type, category, condition HAVING count(*) > 1);”
- Then perform you Database upgrade
I know this seems to be pretty simple but the KB doesn’t tell you specifically what you need to do. The Oracle piece was vague in that one would think you need to run the snippet above to fix it. You should just know that this is something that should be ran AFTER the database restore. This may save you some time if you run into it.
So I was doing some testing in vCloud Director 1.5 and noticed my RHEL Linux 5 vApp wasn’t able to enable Virtual CPU Hot add.
I went in and check my vCenter settings to see what the deal was:
Changing the setting on my vCenter updated it in my vCloud Director..
The alternative to having to do this workaround would be to change the template version within vCloud Director to RHEL version 6
You will notice the Virtual CPU hot add becomes available to check. I used this method on existing templates and it did not seem to break the templates.
However, if you are trying to create new templates of RHEL 6 with RHEL5 5 OS you may want to make sure your SCSI controller is correct. Again, changing it on my vApps seemed to make no impact to my OS currently installed.
It’s apparent bug to vCloud Director and @Lamw was kind enough to help me out.
Alright, this is going to be difficult for me to really explain so I will do my best to serve it justice. First, I am not a coder and I do not know the ins and outs of the API and code. What I will attempt to explain to you is how you can reproduce this issue on your VCD instance. I also want to note this is vanilla VCD 1.5 with no updates yet. I currently do have a case with VMware opened and I have yet to resolve it.
Let’s get to the nitty gritty.
First off, I want to say that I am not 100% sure that any other queries you use produce the same affect. This issue seems to happen with only the VMadmin query.
First I would recommend reading about connecting the Rest API with Will’s blog over at VMware:
Now that you have read that and understand how to connect to the REST API I will show you an example of a basic VMadmin query.
(Note: you need to have over 128 VCD Vapps to reproduce this type of issue)
This showed me that I had 333 queries returned however on the 1st page I only found 128. Now the way the script talked to VCD API was rather plain and it was basically doing this query and dumping it to a XML file. The idea was that this was similar to 1.0 API where I could get all the data I wanted and dumped into an XML file. This wasn’t the case. It seems I couldn’t get around this 128 limit. So I decided to try the next query:
After running it I still got 333 queries returned but only 128 on the single page EVEN after specifying a pageSize=999 so this isn’t the end of it… let’s dig deeper. After further researching I had actually found documented proof that this was a hard setting somewhere.
Page 212 of the VCD 1.5 API Guide taken from here: http://www.vmware.com/pdf/vcd_15_api_guide.pdf
So it became obvious to me at this point that no matter what your query is it would always default to 128 objects per page. So I tried to also do the following to change this hard setting (at the recommendation of someone) located in a global.properties file in the following directory on the vCloud Director cells:
add/change the following: restapi.queryservice.maxPageSize=1024
I added this to the global.properties file and the VCD cells service were also restarted. Can you guess what still happened? Nothing… this didn’t change anything at all. In fact, it still remained broken. Folks, this still wasn’t the worse part about it. Lets cover the part that I believe is a true bug in the API and had someone on Twitter also comment that there is a possible bug in adminVM query.
Lets say I do a query for a pageSize=135 and my query returns 153 results. We get the usual 128 queries per page. Here is an example of the commands I used:
Sort ascending gives me an alphabetical sorting of all my vApp names and I can find a Breaking point for my virtual machines (I know my ABC’s and what should be next so to speak). So I copy and paste the results into Notepad++ and it shows me 128 entries of the page size of 135 (give or take a few for other lines returned not relevant to the query. The bug as discussed is evident. However, it doesn’t show the other 7 entries it should be showing. Remember, we did the page size for 135. So now let’s take a peek at page 2.
So after you run this query you will the list of the remaining 153 results. However if you take notes you will notice that it is in fact completely missing the 7 other entries. So basically your query takes the 7 it could NOT list and dumps it out to somewhere in the Cloud…. So what does this mean aside from the fact that there is a bug?
You will need to use a looping construct and not specify a page size greater then 128. (see Will’s comments below)
This is a bug and I don’t think I could make it any clearer. I wish I could’ve provided some screenshots but I think if someone does there due diligence they will see what I am talking about. If you have 2000 VCD vApps and you do a page size of 500 you would lose 372 queries between each page. No matter how you specify the page size, modify the Global.properties its just broken plain and simple. If someone would like to provide some screen shots I would be happy to put them up here to show some better detail.
If you want to discuss in further detail feel free to comment and I will follow up.
UPDATE: After reviewing with VMware on some things I found out this is actually a true but with the vCloud 1.5 API bug. The good news is that there is a fix slated to be published in August, perhaps they will allow for a private fix if you really need it. Stay tuned. If anyone has some information aside from this please provide and I will link it! Thanks again. Also, this is not related to any type of Query parameter this is more to do with how the Query service works.