Also I think your meaning the vmprofile table.

vmhost table should only contain:

The vmprofile table is to contain all the extra info so one can make better use of normalization and easily define vmprofiles for one or more vmhost. Once you start adding 10, 100 or more vmhost servers it's cleaner to have as little as possible in the vmhost table.

The vmprofile table consists:

profilename     -- name of profile                              

vmtypeid -- links to vmtype->id

imageid -- links to image->id defines the vhost server image

nasshare --  we're not using this one

datastorepath -- path to the vmdks                              

vmpath  -- path to the vmx files could be same as datastorepath

virtualswitch0 -- vmware private switch name for .vmx files     

virtualswitch1 -- vmware public switch name for .vmx files      

vmdisk enum('localdisk', 'networkdisk') -- used in to determine if using local disk on blade or using network mounted datastore

So if that is all that's needed we extend vmprofile table to include the username and password(or some key or a password hash and use mcrypt like Josh mentioned) and suggest to make use of the datastore and vmpath to define where the vmdks are and vmx files are respectively. With that we also need to update the get_vmhost_info routine in

An example of how is using datastore and vmpath - on the vmware Server and the ESX standard server using the vmprofile table to define separate locations for the vmdk files and vmx files on a per-reservation basis. Since under normal user mode(non-image creation) they get a vm that is in "independent-nonpersistent" mode.

on a ESX standard server vmprofile
network mounted datastore for vmdks

local storage is location for the vm's

In the running vm directory it contains the vmx file that points to the vmdk also it contains the memory files, etc.


--On March 10, 2009 8:59:50 AM -0400 Josh Thompson <> wrote:

Hash: SHA1

I've used mcrypt for all encryption in the frontend.  I see perl has an
mcrypt  module available.  So, I'd suggest looking at using it to keep
things in line  with the frontend.

On Monday March 09, 2009, Brian Bouterse wrote:
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 the
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 with
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.


Brian Bouterse
Secure Open Systems Initiative

On Mar 9, 2009, at 4:51 PM, Aaron Peeler wrote:
> Brian,
> 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 I see
> $vmhost_username
> $vmhost_password
> $datastore_ip
> $datastore_share_path
> $from -- is this or could this be similar to the datastorepath
> variable, where the vmdk's are at
> Aaron
> --On March 5, 2009 3:19:20 PM -0500 Brian Bouterse
> <> wrote:
>> Heretofore, VCL SSH's to a hypervisor when it wants to cause some
>> change
>> (ie: provision or deprovision a VM).  The VCL uses pre-shared SSH
>> keys
>> between VCL and the hypervisor to allow the SSHing the authenticate.
>> 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 service
>> which
>> 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
>> places
>> to add this information.
>> 1)  Extend the 'vmhost' table to include a username field and a
>> password
>> field.  This would allow each individual hypervisor to have its own
>> user/pass.  However, if all the hypervisors use the same user/pass
>> then
>> we've just duplicated a lot of data, and it is very hard to change
>> this
>> system wide password later.
>> 2)  Extend the 'vmprofile' table to include a username field and a
>> password.  In this case a group of hypervisors (linked through the
>> same
>> vmprofile) would share a single user/pass.  This would make password
>> changes easier since it only has to be updated in one place, but
>> requires
>> hypervisors to have a consistant username/password across them.
>> Because
>> of the de-duplication of data, and easyness of password changes, I
>> favor
>> of this second option.
>> Whichever table it goes in, here are the lines to be added to the
>> vcl.sql
>> file:
>>  `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
>> password
>> out of the database and into our module as a variable?
>> Best,
>> Brian
>> Brian Bouterse
>> Secure Open Systems Initiative
>> 919.698.8796
> Aaron Peeler
> OIT Advanced Computing
> College of Engineering-NCSU
> 919.513.4571

- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

my GPG/PGP key can be found at
Version: GnuPG v1.4.6 (GNU/Linux)


Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to