Hi Daniel, It doesn't seem to be DB limitation.
The info gets stored in the field body of user_pool which is medium text. mysql> desc user_pool; +---------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+--------------+------+-----+---------+-------+ | oid | int(11) | NO | PRI | NULL | | | name | varchar(128) | YES | UNI | NULL | | | body | mediumtext | YES | | NULL | | | uid | int(11) | YES | | NULL | | | gid | int(11) | YES | | NULL | | | owner_u | int(11) | YES | | NULL | | | group_u | int(11) | YES | | NULL | | | other_u | int(11) | YES | | NULL | | +---------+--------------+------+-----+---------+-------+ 8 rows in set (0.00 sec) The actual content of the body with ~300 keys is ~240K bytes which is much less then the documented (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html) limit of L + 3 bytes, where L < 224 mysql> select body from user_pool where name = "nova" into outfile '/tmp/parag.db1'; Query OK, 1 row affected (0.00 sec) [oneadmin@fermicloud198 ~]$ wc --bytes /tmp/parag.db1 240136 /tmp/parag.db1 Also, the contents of the field in DB are valid base64 encoded. So there is no chance of DB truncating the info. We suspect the limit is somehow artificially imposed in the server. However we were not able to figure out where and how it is configurable. Thanks & Regards +========================================================== | Parag Mhashilkar | Fermi National Accelerator Laboratory, MS 120 | Wilson & Kirk Road, Batavia, IL - 60510 |---------------------------------------------------------- | Phone: 1 (630) 840-6530 Fax: 1 (630) 840-3109 |---------------------------------------------------------- | Wilson Hall, 806E (Nov 8, 2012 - To date) | Wilson Hall, 867E (Nov 17, 2010 - Nov 7, 2012) | Wilson Hall, 863E (Apr 24, 2007 - Nov 16, 2010) | Wilson Hall, 856E (Mar 21, 2005 - Apr 23, 2007) +========================================================== On Oct 15, 2014, at 10:56 AM, Daniel Molina wrote: > Hi Steven, > > It looks like a DB limitation, this information is stored in the user > template. So it should depend on the BODY column type and the DB backend used > > Cheers > > On 11 October 2014 03:58, Steven C Timm <t...@fnal.gov> wrote: > We have been doing bulk tests of the OpenNebula 4.8 econe-server. > With just a straight econe-run-instances we can get up to 1000 VM's (the > limit of our current subnet) > started fairly quickly (about 30 minutes) > > But in practice we are using a more complicated sequence of EC2 calls via > HTCondor. > In particular it is doing a CreateKeyPair call before it launches each VM and > then > calling the RunInstances method with the --keypair option, a unique keypair > for each VM. > After the VM exits, it called a DeleteKeyPair call. > > IT appears there is a hard limit of the number of key pairs that can be > stored in > any one user's template and that hard limit is 301. Any further > CreateKeyPair calls > return with "connection reset by peer" causing HTCondor to mark the VM as > held. > Fortunately it is possible to override this and tell HTCondor to continue, > but it's a pain. > We do have ways to log into the vm's without the ssh key pair so we wouldn't > even really need to register > them at all. > > Is my analysis correct? Is there a hard limit of the number of keys that can > be stored in the user template? > If so, how best to get around this limit? > > Steve Timm > > > > _______________________________________________ > Users mailing list > Users@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > > > > > -- > -- > Daniel Molina > Project Engineer > OpenNebula - Flexible Enterprise Cloud Made Simple > www.OpenNebula.org | dmol...@opennebula.org | @OpenNebula > _______________________________________________ > Users mailing list > Users@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
