[one-users] files datastore

Thu Aug 22 01:45:21 PDT 2013

Hi Michael,

This issue is worked upon in the context of this issue:
http://dev.opennebula.org/issues/2230

It will be available for v4.4, but you can keep track of that ticket
for commits fixing the error.

Best,

-Tino
--
Constantino Vázquez Blanco, PhD, MSc
Senior Infrastructure Architect at C12G Labs
www.OpenNebula.org | @tinova79  | es.linkedin.com/in/tinova

On Wed, Aug 7, 2013 at 2:50 PM, Michael Curran
<michael.curran at connectsolutions.com> wrote:
> Tino --
>
> Is this something that is being worked on now, or for a future release?
>
> Michael Curran | connectsolutions | Lead Network Architect
> Phone 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>
> -----Original Message-----
> From: Tino Vazquez [mailto:tinova79 at gmail.com]
> Sent: Wednesday, July 31, 2013 9:52 AM
> To: Michael Curran
> Cc: users at lists.opennebula.org
> Subject: Re: [one-users] files datastore
>
> Hi Michael,
>
> No, that wouldn't solve the issue. The solution here is to adapt remotes/datastore/vmfs/cp to be able to cope with files and directories that are not vmdk disks.
>
> A redesign needs to be carried out. In particular:
>
>  - Files are failing due to line 154
>  - Directories are failing due to line 146
>
> As soon as we have the solution designed, I'll let you know.
>
> Best,
>
> -Tino
> --
> Constantino Vázquez Blanco, PhD, MSc
> Senior Infrastructure Architect at C12G Labs www.OpenNebula.org | @tinova79  | es.linkedin.com/in/tinova
>
>
> On Mon, Jul 29, 2013 at 7:27 PM, Michael Curran <michael.curran at connectsolutions.com> wrote:
>> So -- This is more of the issue
>>
>> 1) I tried to change it to /vmfs/volumes (doesn't work, doesn't exist
>> on ONE node -- and oneadmin cannot create root , top-level directories
>> -- mkdir fails)
>> 2) The system is only trying to use CP to move files between Files DS and System DS (including moving the context files to a temp location)
>>         -- this doesn't work because CP is local to the ONE node , and
>> the files are on the VMFS volumes on ESXi  -- copy fails
>> 3) I can see my IM/VM/VN set as vmware/vmware/dummy -- but I do not
>> see any settings for TM against the host only in oned.conf
>>
>> If I change this TM_MAD setting in oned.conf from this
>>
>>  TM_MAD = [
>>     name       = "vmware",
>>     executable = "one_tm",
>>     arguments  = "-t 15 -d dummy,lvm,shared,qcow2,ssh,vmfs,iscsi,ceph"
>> ]
>>
>> To this
>>
>> TM_MAD = [
>>     name       = "vmware",
>>     executable = "one_tm",
>>     arguments  = "-t 15 -d vmfs" ]
>>
>> Will that solve the issue of trying to build the context.sh on the ONE node instead of the VMFS volumes?
>>
>>
>> Michael Curran | connectsolutions | Lead Network Architect Phone
>> 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>
>> -----Original Message-----
>> From: users-bounces at lists.opennebula.org
>> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Michael
>> Curran
>> Sent: Monday, July 29, 2013 11:23 AM
>> To: Tino Vazquez
>> Cc: users at lists.opennebula.org
>> Subject: Re: [one-users] files datastore
>>
>> Not sure how I missed this error previously -- but
>>
>> Mon Jul 29 08:14:28 2013 [TM][E]: Error executing image transfer
>> script: Error copying
>> /vmfs/volumes/103/23cd05f1a8455f9aa414ec963a97aaff/startup.vbs to
>> /var/lib/one/datastores/.isofiles/53
>>
>> The transfer job is trying to pull the files from the DS for files, to
>> the local ONE node in /var/lib/one/datastores/.isofiles/53 and then
>> when it gets those files it builds the context.sh / disk.1.iso and
>> pushes it back to the 53 directory on the vmfs volume
>>
>> Shouldn't it be building all of that information on the ESXi volume locally instead of trying to transfer it all over ?
>>
>> Michael Curran | connectsolutions | Lead Network Architect Phone
>> 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>
>> -----Original Message-----
>> From: Michael Curran
>> Sent: Monday, July 29, 2013 11:11 AM
>> To: Michael Curran; Tino Vazquez
>> Cc: users at lists.opennebula.org
>> Subject: RE: [one-users] files datastore
>>
>> Still working on this -- is there a way to manually build the context.sh and disk.1.iso for use during the boot process?
>>
>> Michael Curran | connectsolutions | Lead Network Architect Phone
>> 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>
>> -----Original Message-----
>> From: users-bounces at lists.opennebula.org
>> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Michael
>> Curran
>> Sent: Friday, July 26, 2013 2:25 PM
>> To: Tino Vazquez
>> Cc: users at lists.opennebula.org
>> Subject: Re: [one-users] files datastore
>>
>> One resolved (in a workaround) -- another one shows up --
>>
>> Fri Jul 26 09:47:12 2013 [TM][I]: Command execution fail:
>> /var/lib/one/remotes/tm/vmfs/context /var/lib/one/vms/51/context.sh
>> :'one-context.ps' :'README.txt' :'SetupComplet.cmd' :'startup.vbs'
>> :'windows.one' 192.168.250.34:/vmfs/volumes/0/51/disk.1 51 0 Fri Jul
>> 26 09:47:12 2013 [TM][I]: context: Generating context block device at
>> 192.168.250.34:/vmfs/volumes/0/51/disk.1
>> Fri Jul 26 09:47:12 2013 [TM][E]: context: Command "cp -R  /var/lib/one/datastores/.isofiles/51/'one-context.ps'" failed: cp: missing destination file operand after `/var/lib/one/datastores/.isofiles/51/one-context.ps'
>> Fri Jul 26 09:47:12 2013 [TM][I]: Try `cp --help' for more information.
>> Fri Jul 26 09:47:12 2013 [TM][E]: Error copying  to
>> /var/lib/one/datastores/.isofiles/51
>> Fri Jul 26 09:47:12 2013 [TM][I]: ExitCode: 255
>>
>>
>> So looking at these errors -- the context error relates to the fact
>> that it is trying to generate the context block device from the
>> /var/lib/one/datastores/.isofiles
>>
>> All of my files reside on the /vmfs/volumes/103 filestore DS and my
>> template calls them out like this
>>
>>   FILES="/vmfs/volumes/103/23cd05f1a8455f9aa414ec963a97aaff/startup.vbs /vmfs/volumes/103/6564273ad2c2154a3af6c2ccfcb73a41/one-context.ps1 /vmfs/volumes/103/1f9e29f457450fb983877faf25406cf3/README.txt /vmfs/volumes/103/1f9e29f457450fb983877faf25406cf3/SetupComplete.cmd /vmfs/voluems/103/fbf51b0fc2f8939dc7d2534a728b2f03/windows.one"
>>
>> The initial PROLOG copy completes normally, then I get the fails above -- and the /var/lib/one/datastores/.isofiles directory is empty -- presumably because all my actual used datastores are on /vmfs/volumes/ -- shouldn't the .isofiles directory exist there?
>>
>> The Windows image which shows up as disk.0 , is there as expected The
>> context CDROM fails to build, because its trying to pull the
>> context.sh from an empty directory
>>
>>
>> Michael Curran | connectsolutions | Lead Network Architect Phone
>> 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>
>> -----Original Message-----
>> From: Tino Vazquez [mailto:tinova79 at gmail.com]
>> Sent: Friday, July 26, 2013 11:00 AM
>> To: Michael Curran
>> Cc: users at lists.opennebula.org
>> Subject: Re: [one-users] files datastore
>>
>> Hi Michael,
>>
>> That is indeed a bug. The VMFS drivers cannot cope with the files datastore, they always assume it is a VMware vmdk disk.
>>
>> I've opened a ticket [1] to keep track of the solution.
>>
>> Thanks for the great feedback!
>>
>> -Tino
>>
>> [1] http://dev.opennebula.org/issues/2230
>> --
>> Constantino Vázquez Blanco, PhD, MSc
>> Senior Infrastructure Architect at C12G Labs www.OpenNebula.org |
>> @tinova79  | es.linkedin.com/in/tinova
>>
>>
>> On Fri, Jul 26, 2013 at 4:40 PM, Michael Curran <michael.curran at connectsolutions.com> wrote:
>>> I get the same error when I upload a file image with the oneimage CLI
>>> command - the issue is the SCP command for a file should look more
>>> like this
>>>
>>>
>>>
>>> oneadmin at u-cmh-neb-dev01:~/tmp$ scp
>>> /var/lib/one/tmp/6564273ad2c2154a3af6c2ccfcb73a41
>>> oneadmin at 192.168.250.34:/vmfs/volumes/103/6564273ad2c2154a3af6c2ccfcb
>>> 7
>>> 3a41/one-context.ps
>>>
>>> 6564273ad2c2154a3af6c2ccfcb73a41
>>> 100% 4866     4.8KB/s   00:00
>>>
>>>
>>>
>>> It should take the tmp file name and SCP it to the filestore and
>>> rename the file to the original name of one-context.ps - instead the
>>> command expects the tempname to be a directory
>>>
>>>
>>>
>>> This wouldn't be a problem if the during the creation of the temp
>>> name , it created a directory with a file in the temp name location,
>>> but the copy to the temp location is copying the file as the temp name.
>>> Then it cannot upload it to the VMFS datastore - because a directory
>>> is expected
>>>
>>>
>>>
>>> I can work around this by running the SCP command manually as shown
>>> above, but then the images created by the oneimage create CLI stay in
>>> an ERR state, they don't show ready or used
>>>
>>>
>>>
>>> Michael Curran | connectsolutions | Lead Network Architect
>>>
>>> Phone 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>>
>>>
>>>
>>> From: users-bounces at lists.opennebula.org
>>> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Michael
>>> Curran
>>> Sent: Friday, July 26, 2013 9:35 AM
>>> To: users at lists.opennebula.org
>>> Subject: [one-users] files datastore
>>>
>>>
>>>
>>> I am uploading some files to a files datastore I have for use with
>>> creating the context.sh for windows automation -
>>>
>>>
>>>
>>> When I go to the Files and Kernels tab and do a create
>>>
>>>
>>>
>>> I enter the name of the file I am uploading - change it to type
>>> Context and the to the Files datastore - provide a path on the one
>>> node where I have the files and I get this error
>>>
>>>
>>>
>>> Fri Jul 26 06:14:43 2013 [ImM][I]: Command execution fail:
>>> /var/lib/one/remotes/datastore/vmfs/cp
>>> PERTX0RSSVZFUl9BQ1RJT05fREFUQT4
>>>
>>> 8SU1BR0U+PElEPjQwPC9JRD48VUlEPjA8L1VJRD48R0lEPjA8L0dJRD48VU5BTUU+b25lYWRtaW48L1VOQU1FPjxHTkFNRT5vbmVhZG1pbjwvR05BTUU+PE5BTUU+d2lu
>>>
>>> ZG93cy5vbmU8L05BTUU+PFBFUk1JU1NJT05TPjxPV05FUl9VPjE8L09XTkVSX1U+PE9XTkVSX00+MTwvT1dORVJfTT48T1dORVJfQT4wPC9PV05FUl9BPjxHUk9VUF9VP
>>>
>>> jA8L0dST1VQX1U+PEdST1VQX00+MDwvR1JPVVBfTT48R1JPVVBfQT4wPC9HUk9VUF9BPjxPVEhFUl9VPjA8L09USEVSX1U+PE9USEVSX00+MDwvT1RIRVJfTT48T1RIRV
>>>
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+NTwvVFlQRT48RElTS19UWVB
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+F
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+PjA8L0RJU0tfVFlQRT48UEV
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+S
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+U0lTVEVOVD4wPC9QRVJTSVN
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+U
>>> JfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PFRZUEU+RU5UPjxSRUd
>>>
>>> USU1FPjEzNzQ4NDQ0ODI8L1JFR1RJTUU+PFNPVVJDRT48L1NPVVJDRT48UEFUSD4vdmFyL3RtcC93aW5kb3dzX3NldHVwL3dpbmRvd3Mub25lPC9QQVRIPjxGU1RZUEU+
>>>
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+PFJVTk5JTkdfVk1TP
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+j
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+A8L1JVTk5JTkdfVk1
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+T
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+PjxDTE9OSU5HX09QU
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+z
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+4wPC9DTE9OSU5HX09
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+Q
>>> PC9GU1RZUEU+PFNJWkU+MTwvU0laRT48U1RBVEU+NDwvU1RBVEU+Uz48Q
>>>
>>> 0xPTklOR19JRD4tMTwvQ0xPTklOR19JRD48REFUQVNUT1JFX0lEPjEwMzwvREFUQVNUT1JFX0lEPjxEQVRBU1RPUkU+RmlsZXM8L0RBVEFTVE9SRT48Vk1TPjwvVk1TPj
>>>
>>> xDTE9ORVM+PC9DTE9ORVM+PFRFTVBMQVRFPjwvVEVNUExBVEU+PC9JTUFHRT48REFUQVNUT1JFPjxJRD4xMDM8L0lEPjxVSUQ+MDwvVUlEPjxHSUQ+MDwvR0lEPjxVTkF
>>>
>>> NRT5vbmVhZG1pbjwvVU5BTUU+PEdOQU1FPm9uZWFkbWluPC9HTkFNRT48TkFNRT5GaWxlczwvTkFNRT48UEVSTUlTU0lPTlM+PE9XTkVSX1U+MTwvT1dORVJfVT48T1dO
>>>
>>> RVJfTT4xPC9PV05FUl9NPjxPV05FUl9BPjA8L09XTkVSX0E+PEdST1VQX1U+MTwvR1JPVVBfVT48R1JPVVBfTT4wPC9HUk9VUF9NPjxHUk9VUF9BPjA8L0dST1VQX0E+P
>>>
>>> E9USEVSX1U+MDwvT1RIRVJfVT48T1RIRVJfTT4wPC9PVEhFUl9NPjxPVEhFUl9BPjA8L09USEVSX0E+PC9QRVJNSVNTSU9OUz48RFNfTUFEPnZtZnM8L0RTX01BRD48VE
>>>
>>> 1fTUFEPnZtZnM8L1RNX01BRD48QkFTRV9QQVRIPi92bWZzL3ZvbHVtZXMvMTAzPC9CQVNFX1BBVEg+PFRZUEU+MjwvVFlQRT48RElTS19UWVBFPjA8L0RJU0tfVFlQRT4
>>>
>>> 8Q0xVU1RFUl9JRD4xMDA8L0NMVVNURVJfSUQ+PENMVVNURVI+cHJvZHVjdGlvbjwvQ0xVU1RFUj48VE9UQUxfTUI+MTM0OTEyPC9UT1RBTF9NQj48RlJFRV9NQj4xMzA1
>>>
>>> NTc8L0ZSRUVfTUI+PFVTRURfTUI+NDE1NDwvVVNFRF9NQj48SU1BR0VTPjxJRD4zNjwvSUQ+PElEPjM3PC9JRD48SUQ+Mzg8L0lEPjxJRD4zOTwvSUQ+PC9JTUFHRVM+P
>>>
>>> FRFTVBMQVRFPjxCUklER0VfTElTVD48IVtDREFUQVsxOTIuMTY4LjI1MC4zNF1dPjwvQlJJREdFX0xJU1Q+PERJU0tfVFlQRT48IVtDREFUQVtmaWxlXV0+PC9ESVNLX1
>>>
>>> RZUEU+PERTX01BRD48IVtDREFUQVt2bWZzXV0+PC9EU19NQUQ+PERTX1VTRV9TU0g+PCFbQ0RBVEFbWUVTXV0+PC9EU19VU0VfU1NIPjxUTV9NQUQ+PCFbQ0RBVEFbdm1
>>>
>>> mc11dPjwvVE1fTUFEPjxUTV9VU0VfU1NIPjwhW0NEQVRBW1lFU11dPjwvVE1fVVNFX1NTSD48VFlQRT48IVtDREFUQVtGSUxFX0RTXV0+PC9UWVBFPjwvVEVNUExBVEU+
>>>
>>> PC9EQVRBU1RPUkU+PC9EU19EUklWRVJfQUNUSU9OX0RBVEE+ 40
>>>
>>> Fri Jul 26 06:14:43 2013 [ImM][E]: cp: Command "scp -r
>>> /var/lib/one/tmp/fbf51b0fc2f8939dc7d2534a728b2f03/*
>>> 192.168.250.34:/vmfs/v
>>>
>>> olumes/103/fbf51b0fc2f8939dc7d2534a728b2f03" failed:
>>> /var/lib/one/tmp/fbf51b0fc2f8939dc7d2534a728b2f03/*: Not a directory
>>>
>>> Fri Jul 26 06:14:43 2013 [ImM][E]: Error copying
>>> /var/lib/one/tmp/fbf51b0fc2f8939dc7d2534a728b2f03 to
>>> /vmfs/volumes/103/fbf51b0fc
>>>
>>> 2f8939dc7d2534a728b2f03 through SCP
>>>
>>> Fri Jul 26 06:14:43 2013 [ImM][I]: ExitCode: 1
>>>
>>> Fri Jul 26 06:14:43 2013 [ImM][E]: Error copying image in the datastore:
>>> Error copying /var/lib/one/tmp/fbf51b0fc2f8939dc7d2534a7
>>>
>>> 28b2f03 to /vmfs/volumes/103/fbf51b0fc2f8939dc7d2534a728b2f03 through
>>> SCP
>>>
>>>
>>>
>>> At that point it looks like the SCP is expecting the temporary
>>> location to be a directory instead of a file, so I decide to let it
>>> upload the whole directory instead of one file and I get this error
>>> instead
>>>
>>>
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][I]: Command execution fail:
>>> /var/lib/one/remotes/datastore/vmfs/cp
>>> PERTX0RSSVZFUl9BQ1RJT05fREFUQT4
>>>
>>> 8SU1BR0U+PElEPjQxPC9JRD48VUlEPjA8L1VJRD48R0lEPjA8L0dJRD48VU5BTUU+b25lYWRtaW48L1VOQU1FPjxHTkFNRT5vbmVhZG1pbjwvR05BTUU+PE5BTUU+d2lu
>>>
>>> ZG93c19zZXR1cDwvTkFNRT48UEVSTUlTU0lPTlM+PE9XTkVSX1U+MTwvT1dORVJfVT48T1dORVJfTT4xPC9PV05FUl9NPjxPV05FUl9BPjA8L09XTkVSX0E+PEdST1VQX
>>>
>>> 1U+MDwvR1JPVVBfVT48R1JPVVBfTT4wPC9HUk9VUF9NPjxHUk9VUF9BPjA8L0dST1VQX0E+PE9USEVSX1U+MDwvT1RIRVJfVT48T1RIRVJfTT4wPC9PVEhFUl9NPjxPVE
>>>
>>> hFUl9BPjA8L09USEVSX0E+PC9QRVJNSVNTSU9OUz48VFlQRT41PC9UWVBFPjxESVNLX1RZUEU+MDwvRElTS19UWVBFPjxQRVJTSVNURU5UPjA8L1BFUlNJU1RFTlQ+PFJ
>>>
>>> FR1RJTUU+MTM3NDg0NTI3MjwvUkVHVElNRT48U09VUkNFPjwvU09VUkNFPjxQQVRIPi92YXIvdG1wL3dpbmRvd3Nfc2V0dXA8L1BBVEg+PEZTVFlQRT48L0ZTVFlQRT48
>>>
>>> U0laRT4xPC9TSVpFPjxTVEFURT40PC9TVEFURT48UlVOTklOR19WTVM+MDwvUlVOTklOR19WTVM+PENMT05JTkdfT1BTPjA8L0NMT05JTkdfT1BTPjxDTE9OSU5HX0lEP
>>>
>>> i0xPC9DTE9OSU5HX0lEPjxEQVRBU1RPUkVfSUQ+MTAzPC9EQVRBU1RPUkVfSUQ+PERBVEFTVE9SRT5GaWxlczwvREFUQVNUT1JFPjxWTVM+PC9WTVM+PENMT05FUz48L0
>>>
>>> NMT05FUz48VEVNUExBVEU+PC9URU1QTEFURT48L0lNQUdFPjxEQVRBU1RPUkU+PElEPjEwMzwvSUQ+PFVJRD4wPC9VSUQ+PEdJRD4wPC9HSUQ+PFVOQU1FPm9uZWFkbWl
>>>
>>> uPC9VTkFNRT48R05BTUU+b25lYWRtaW48L0dOQU1FPjxOQU1FPkZpbGVzPC9OQU1FPjxQ
>>> uPC9VTkFNRT48R05BTUU+R
>>> uPC9VTkFNRT48R05BTUU+VJNSVNTSU9OUz48T1dORVJfVT4xPC9PV05FUl9VPjxPV05FU
>>> uPC9VTkFNRT48R05BTUU+l
>>> uPC9VTkFNRT48R05BTUU+9NPjE8L09X
>>>
>>> TkVSX00+PE9XTkVSX0E+MDwvT1dORVJfQT48R1JPVVBfVT4xPC9HUk9VUF9VPjxHUk9VUF9NPjA8L0dST1VQX00+PEdST1VQX0E+MDwvR1JPVVBfQT48T1RIRVJfVT4wP
>>>
>>> C9PVEhFUl9VPjxPVEhFUl9NPjA8L09USEVSX00+PE9USEVSX0E+MDwvT1RIRVJfQT48L1BFUk1JU1NJT05TPjxEU19NQUQ+dm1mczwvRFNfTUFEPjxUTV9NQUQ+dm1mcz
>>>
>>> wvVE1fTUFEPjxCQVNFX1BBVEg+L3ZtZnMvdm9sdW1lcy8xMDM8L0JBU0VfUEFUSD48VFlQRT4yPC9UWVBFPjxESVNLX1RZUEU+MDwvRElTS19UWVBFPjxDTFVTVEVSX0l
>>>
>>> EPjEwMDwvQ0xVU1RFUl9JRD48Q0xVU1RFUj5wcm9kdWN0aW9uPC9DTFVTVEVSPjxUT1RB
>>> T F9NQj4xMzQ5MTI8L1RPVEFMX01CPjxGUkVFX01CPjEzMDU1NzwvRlJFRV9N
>>>
>>> Qj48VVNFRF9NQj40MTU0PC9VU0VEX01CPjxJTUFHRVM+PElEPjM2PC9JRD48SUQ+Mzc8L0lEPjxJRD4zODwvSUQ+PElEPjM5PC9JRD48SUQ+NDA8L0lEPjwvSU1BR0VTP
>>>
>>> jxURU1QTEFURT48QlJJREdFX0xJU1Q+PCFbQ0RBVEFbMTkyLjE2OC4yNTAuMzRdXT48L0JSSURHRV9MSVNUPjxESVNLX1RZUEU+PCFbQ0RBVEFbZmlsZV1dPjwvRElTS1
>>>
>>> 9UWVBFPjxEU19NQUQ+PCFbQ0RBVEFbdm1mc11dPjwvRFNfTUFEPjxEU19VU0VfU1NIPjw
>>> 9UWVBFPjxEU19NQUQ+h
>>> 9UWVBFPjxEU19NQUQ+W0NEQVRBW1lFU11dPjwvRFNfVVNFX1NTSD48VE1fTUFEPjwhW0N
>>> 9UWVBFPjxEU19NQUQ+E
>>> 9UWVBFPjxEU19NQUQ+QVRBW3Z
>>>
>>> tZnNdXT48L1RNX01BRD48VE1fVVNFX1NTSD48IVtDREFUQVtZRVNdXT48L1RNX1VTRV9TU0g+PFRZUEU+PCFbQ0RBVEFbRklMRV9EU11dPjwvVFlQRT48L1RFTVBMQVRF
>>>
>>> PjwvREFUQVNUT1JFPjwvRFNfRFJJVkVSX0FDVElPTl9EQVRBPg== 41
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][I]: cp: Copying local disk folder
>>> /var/tmp/windows_setup to the image repository
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][E]: cp: Command "mv -f
>>> /var/tmp/windows_setup/ /var/tmp/windows_setup/disk.vmdk" failed: mv:
>>> canno
>>>
>>> t move `/var/tmp/windows_setup/' to a subdirectory of itself,
>>> `/var/tmp/windows_setup/disk.vmdk'
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][E]: Error renaming file
>>> /var/tmp/windows_setup/ to /var/tmp/windows_setup/disk.vmdk
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][I]: ExitCode: 1
>>>
>>> Fri Jul 26 06:27:53 2013 [ImM][E]: Error copying image in the datastore:
>>> Error renaming file /var/tmp/windows_setup/ to /var/tmp/
>>>
>>> windows_setup/disk.vmdk
>>>
>>>
>>>
>>>
>>>
>>> Now it thinks I am uploading a disk.vmdk OS image instead? I should
>>> just be able to upload a single file - will try from the oneimage CLI
>>> command to see if the behavior is limited to SunStone GUI.
>>>
>>>
>>>
>>> Michael Curran | connectsolutions | Lead Network Architect
>>>
>>> Phone 614.568.2285 | Mobile 614.403.6320 | www.connectsolutions.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org