ok, np.
I'll go ahead and update both the database and get_vmhost_info routine in
utils.pm.
Encrypting the password - (I think you also mentioned this), but it might
be easier to use plain text on the password field at first and then once
that is working - encrypt the password via some method. This will also have
be synced with the front-end so VCLadmins and edit the vmprofiles.
Aaron
--On March 10, 2009 11:10:01 AM -0400 Brian Bouterse bmbou...@ncsu.edu
wrote:
You are correct, I misspoke in my previous note. What I meant to say
was: We need the 'username' and 'password' fields added to vmprofile
Sorry for the confusion.
-Brian
Brian Bouterse
Secure Open Systems Initiative
919.698.8796
On Mar 10, 2009, at 9:14 AM, Aaron Peeler wrote:
Also I think your meaning the vmprofile table.
vmhost table should only contain:
id
computerid
vmliimt
vmprofileid
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:
id
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 vmware.pm 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 utils.pm.
An example of how vmware.pm is using datastore and vmpath - on the
vmware Server and the ESX standard server vmware.pm 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.
i.e.
on a ESX standard server vmprofile
datastore=/vmfs/volumes/Netapp
network mounted datastore for vmdks
/vmfs/volumes/Netapp/vmwareesx-base1-v0/
vmpath=/vmfs/volumes/Storage1
local storage is location for the vm's
/vmfs/volumes/Storage1/vmwareesx-base1-v0vclv1-1/
In the running vm directory it contains the vmx file that points to
the vmdk also it contains the memory files, etc.
Aaron
--On March 10, 2009 8:59:50 AM -0400 Josh Thompson
josh_thomp...@ncsu.edu
wrote:
-BEGIN PGP SIGNED MESSAGE-
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
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 esx.pm 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
bmbou...@ncsu.edu 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
