I already upgraded to 26026 before 26027 was posted and will upgrade to this after the workshop and as soon as I fixed some other issues with the vbox_control script. I would also like to update Linux and Mac OS to the same version so we have the same behaviour on all Operating Systems.
Regards Christian Am 21.09.2013 08:53, schrieb Lammert van der Veen: > It works: > > > Cheers, > Lammert > > > ----- Original Message ----- > *From:* Rom Walton <mailto:[email protected]> > *To:* Lammert van der Veen <mailto:[email protected]> ; > Christian Beer <mailto:[email protected]> > *Cc:* David Anderson (BOINC) <mailto:[email protected]> ; Ben > Segal <mailto:[email protected]> ; BOINCDev Mailing List > <mailto:[email protected]> > *Sent:* Friday, September 20, 2013 5:34 PM > *Subject:* RE: VBoxwrapper 26026 VM-names > > Okay, I've posted 26027: > > x86: > http://boinc.berkeley.edu/dl/vboxwrapper_26027_windows_intelx86.zip > > x64: http://boinc.berkeley.edu/dl/vboxwrapper_26027_windows_x86_64.zip > > > > Christian, if you haven't already started your next round of beta > testing you should use this build. It turns out using the slot id > was not a good idea. Vboxwrapper has some recovery logic to clean > up after a failed VM execution, but the logic assumes that the VM > names are different for each result in a slot directory. > > > > ----- Rom > > > > *From:*Lammert van der Veen [mailto:[email protected]] > *Sent:* Friday, September 20, 2013 10:50 AM > *To:* Rom Walton > *Cc:* David Anderson (BOINC); Ben Segal; Christian Beer; BOINCDev > Mailing List > *Subject:* Re: VBoxwrapper 26026 VM-names > > > > Hi Rom, > > > > Everything that makes a VM-name unique is better than the > possibility of same names. > > We've had enough headache with the default name BOINC_VM T4T > was/is using with the old CERN-wrapper ;) > > > > Theoretical you could even with 1 BOINC-instance become that 'in > use' boinc__slot_x situation, > > when the VM wasn't cleared properly and/or still exist in > VirtualBox.xml, but the used slot folder is emptied for a new > vboxwrapper-task. > > > > Cheers, > > > > Lammert > > > > > > ----- Original Message ----- > > *From:*Rom Walton <mailto:[email protected]> > > *To:*Lammert van der Veen <mailto:[email protected]> > > *Cc:*David Anderson (BOINC) <mailto:[email protected]> ; > Ben Segal <mailto:[email protected]> ; Christian Beer > <mailto:[email protected]> ; BOINCDev Mailing List > <mailto:[email protected]> > > *Sent:*Friday, September 20, 2013 4:07 PM > > *Subject:*RE: VBoxwrapper 26026 VM-names > > > > How about using the MD5 hash of the result name and using the > first 16 characters as part of the VM name? > > > > It would look something like: > > boinc_A2579B43234C3456 > > > > It will look a little random to volunteers, but it will keep > the names from clashing across multiple instances of BOINC > running on the same machine. > > > > ----- Rom > > > > *From:*Lammert van der Veen [mailto:[email protected]] > *Sent:* Friday, September 20, 2013 8:20 AM > *To:* Rom Walton > *Cc:* David Anderson (BOINC); Ben Segal > *Subject:* VBoxwrapper 26026 VM-names > > > > Hello Rom, > > > > I noticed you introduced a new way to name the VM's in the > newest vboxwrapper. > > > > - simple boinc__slot_x where x is the slot number. > > > > I know I'm not an average cruncher, but may attend you on the > following situation: > > > > You are able to run several BOINC clients on a host with each > its own BOINC data-directory > > Nowadays machines has tens of threads, but in principle also > on a dual core it may happen. > > > > I had 8 T4T VM's running on an i7 2600 hyperthreaded and in > your chosen solution for RNA long VM-names, I (and probably > more vbox users) get a problem, > > because now we would get same VM names like boinc__slot_0. You > know VirtualBox doesn't accept that. > > > > In my opinion RNA (Christian) should use shorter Work Unit > names and use the VM description field for the extreme long > bacteria/virus names. > > > > Kind regards, > > > > Lammert > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
