Can you do an export from the gui or w/ the export commands ?
There are some samples in the BLCLI documentation: https://docs.bmc.com/docs/display/public/bsa85/Virtualization+concepts
... but you can probably also find the XML by looking at the staging area of your vCenter (or equivalent), when a VGJ is running.
Thanks, I got that already thought. The thing is that I'm going to be provisioning using VM templates, which means that when I create the VGJ XML, if I want to modify some of the info, I still need to put the whole Platform section and it has to match exactly what is defined in the VGP. If I need to automate that, and that we have a lot of VGPs (which we/ll have) this means I'd have to maintain a static XML reference for each VGP's settings so that I can reuse it when creating customized clones with them.
If I could simply dynamically generate the XML of a VGP, all I would have to do then is copy the part that has to be the same and simply replace or add the values that I want to change or add in it. There is no such thing however from what I can see now.
I have however managed to find pretty much all the database tables where the information is kept and should be able to write my own Perl script that will fetch it and build the XML on the fly.
My end-goal is to have a single job that would read settings from a structured CSV ot Tab-Delimited file, and would launch multiple clones at once including all the pre and post actons that need to be taken (i.e. adding DNS entries, settings target properties, updating them, doing some agent validation, and finally launching all the post config jobs to deploy and install software on the new cloned VM).
I have two suggestions:
1. something more object oriented, where you could possibly do most of the prep work from the GUI:
You could possibly create Component Template with local configuration files that point on your template VGP/VGJ XMLs, then create a Component for the server hosting these files, that way you will be able to:
- benefit from the XML grammars,
- deploy a basic XML into some location,
- insert your specific configuration using the Configuration File modeling.
You could also create additional Components to hold the specific target configuration you want to apply, then use these components as targets for your BLPackage. This would allow you to generate customized XMLs on the fly.
2. you could possibly mimic some of the latter scenario with a script. I wrote something similar for a customer a few years ago. I ended up with a script that was invoked with a number of parameters (the actual configuration of the VM) and a second script used to do mass production, that would essentially invoke the first one as many times as there are VMs.
On a slightly different note, I would not recommend that you rely on requests into the DB, because as the schema is not openly documented, which means that BMC can freely modify the schema from one version to the other with no guarantee of backwards compatibility for your scripts.
The first suggestion doesn't leave enough room for customization (per run) input and is rather "bulky". I tend to stay away from the component and config objects except when used exactly for what they were meant for.
The second suggestion is where I'm going. The only thing is that the blcli commands that exist to fetch some of the required data I need to insert in my XML are not covering enough to be able to replicate a VGP's Platform section entirely (i.e. there is no blcli to get the data for the disks or network interfaces for example), which leaves me no choice but to use database queries to do it. In case that wasn't clear, when using a VM template as the source of a VGP, the VGJ's, and that you need to change some of the platform section's settings while deploying a new VM, you need to replicate the entire section as it is in the VGP even if you only want to change a single setting. If you try to put something that doesn't match, you get a clear error saying so.
We will possibly have around 50 different templates, each wrapped in their own VGP, so I do need something dynamic that can generate the XML data I need without having to manually enter it (and risking human errors).
Besides, I have been poking in the BSA core db since 7.6 and the main schemas haven't changed much at all, and if they do change them it's because the core feature will have changed too and it's not the only thing I'll have to redo anyway. It's a risk I'm willing to take. We already have a lot of scripts that pull data directly from the db, so we're used to it.
Argh....Are you already a step further with this ?
Have the same issue ahead of me.
ehm not sure if i missed something but isn't the following exactly delivering what you require ?
This is from the 8.6 Docs, not too sure if it was there in earlier versions.
So in short
blcli Virtualization getVirtualGuestPackage
[VGPackageID]gives me the complete XML from the VGP including the PlatformSection.Steffen
Ohh ! /facepalm I guess I missed or skipped that command somehow when I browsed the documentation for it. I could have used that, so now I just need to write a script that's able to parse it so I can reuse or modify the parts I need and insert extra disks or extra nics if needed.
maybe you already figured this out.
I'm wondering how to define the "Server Properties" Tab of the VGJ.
As those are the Properties that the later enrolled Server Object has, these are quite important for us, but i haven't figured out how to set them.
I don't think you can... I've asked the same thing to BMC and haven't received a response yet. However, since I'm going to use a launcher NSH Script job to do the provisioning (reading an input file so I can provision multiple VMs at once), I'm just going to use blcli to set the target properties after the VM is created, and before executing any post-provisioning jobs against it to install software or other configurations.
My goal is to have this:
1. Multiple VGP, pointing to multiple vanilla VMware VM templates across multiple vCenter servers (we have several)
2. Sets of "LEGO Brick" type jobs that I can bundle together in a batch in order to complete the build of any provisioned server (selecting which software/components I want to install on the server after the provisioning job is done)
3. Master input file that supports a simple, yet complete syntax to specify all customizable virtual guest settings, server properties and any other special setting required in order to run the full end to end provisioning of a guest.
4. NSH Script Job (calling various other scripts as required, such as a Perl script to generate the VGJ xml) that would parse the input file line by line and run the following steps for each VM to provision:
a) Create a temporary DNS entry using the vm name
b) Create and call the VGJ
c) Rename the target following our internal naming convention (different than VM's name)
d) Delete temp DNS entry and create new one
e) Set server properties using blcli
f) Update agent's properties (using USP job)
g) Push ACL
h) Distribute COs
i) Execute any post-provisioning batch job bundle to complete deployment and configuration of server
The Perl script I mentioned above is only for step 4b. The rest will most likely all be NSH and blcli.
1 of 1 people found this helpful
yeah - i think like you saw it's not all in the xml - it's in job options, explict settings on the job and package object, etc. imo we should have all of this stuff available in the xml. i'd actually update steffen's idea to say include all possible setting in the xml, and having a xml-export ability like you (yanick) started this w/ would be good too so you could set it all up manually and then see how it looks in the xml. right now you are left w/ loading the object in the blcli and running the various 'get' commands against it and seeing what's what.