All we'll need are the 'username' and 'password' to vmhost? I've
updated the code to the example below based on feedback. I've set
username length to 32 which should be long enough, but I'm not sure
about the password. We want the ability to encrypt this later on
a private key. Any ideas here?
`username` varchar(32) NULL default 'NULL'
`password` varchar(128) NULL default 'NULL'
Also, does the code exist for us to have access to the already
existing 'datastorepath' field in the vmhost table? We can use that
for the rest of our datastore info for now.
Secure Open Systems Initiative
On Mar 9, 2009, at 4:51 PM, Aaron Peeler wrote:
> Do you have a list of additional variables? Or is the username and
> password all that's needed to be added to the vmprofile table?
> Just glancing at esx.pm I see
> $from -- is this or could this be similar to the datastorepath
> variable, where the vmdk's are at
> --On March 5, 2009 3:19:20 PM -0500 Brian Bouterse
> <bmbou...@ncsu.edu> wrote:
>> Heretofore, VCL SSH's to a hypervisor when it wants to cause some
>> (ie: provision or deprovision a VM). The VCL uses pre-shared SSH
>> between VCL and the hypervisor to allow the SSHing the
>> This works for VMware server and regular ESX because they are
>> configurable to accept SSH keys. ESX 3i isn't configurable to
>> accept an
>> SSH logon, and can only be communicated with through a web
>> requires a valid hypervisor username and password.
>> So I'd like to propose that we add a hypervisor username and
>> password in
>> the VCL database associated. As far as I can tell, there are two
>> to add this information.
>> 1) Extend the 'vmhost' table to include a username field and a
>> field. This would allow each individual hypervisor to have its
>> user/pass. However, if all the hypervisors use the same user/
>> we've just duplicated a lot of data, and it is very hard to
>> system wide password later.
>> 2) Extend the 'vmprofile' table to include a username field
>> password. In this case a group of hypervisors (linked through
>> vmprofile) would share a single user/pass. This would make
>> changes easier since it only has to be updated in one place, but
>> hypervisors to have a consistant username/password across them.
>> of the de-duplication of data, and easyness of password
>> of this second option.
>> Whichever table it goes in, here are the lines to be added to the
>> `username` varchar(8) NOT NULL default ''
>> `password` varchar(40) NOT NULL default ''
>> Could someone tell us a bit about how to get that username and
>> out of the database and into our module as a variable?
>> Brian Bouterse
>> Secure Open Systems Initiative
> Aaron Peeler
> OIT Advanced Computing
> College of Engineering-NCSU