[one-users] 3.4.0 and HISTORY

Tue Apr 17 07:53:29 PDT 2012

I've not yet tried 3.4, but I've noticed a problem with 3.2.1 and 3.3.0
where when a VM with a non-unique name is created, that similar symptoms
are observed. This was causing my VM restores from the SUSPENDED state
to fail, because ONE was having it go into a PROLOG instead of a
PROLOG_RESUME state (not remembering why at the moment, but something to
do with the value of the REASON or PxTIME values). I eventually was able
to figure out that the SQLPool object was getting confused, because I
think it assumes that every object that uses it must have a unique name.
This causes it to sometimes overwrite HISTORY values.

The attached patch to (to 3.3.0) solves my problem. I would have
submitted it upstream, but I might not consider it the "right" solution
and haven't had the time to get it into what I would consider a
reasonable state. But FWIW, here it is.

On Tue, Apr 17, 2012 at 09:53:07AM -0400, Carlos Martín Sánchez wrote:
> Hi Chris,
> 
> It is indeed a bug. At first I wasn't able to reproduce the problem, then I
> realized you were creating VM directly from a template file rather than using
> onetemplate.
> 
> We are looking into it [1]. Meanwhile, could you please try to create the VMs
> with "onetemplate instantiate" [2], and see it the problem disappears?
> 
> Regards,
> Carlos
> 
> [1] http://dev.opennebula.org/issues/1237
> [2] http://opennebula.org/documentation:rel3.4:vm_guide
> 
> --
> Carlos Martín, MSc
> Project Engineer
> OpenNebula - The Open-source Solution for Data Center Virtualization
> www.OpenNebula.org | cmartin at opennebula.org | @OpenNebula 
> 
> 
> 
> On Mon, Apr 16, 2012 at 11:09 PM, Chris Johnston <chjohnston at rim.com> wrote:
> 
>     Hi all,
> 
>     Has anyone else noticed that HISTORY records are corrupted when there are
>     simultaneous VM actions? And some actions leave VMs, in particular a fail
>     to livemigrate, with a bad history preventing a further live migration? It
>     seems that update_history is failing at least for sqlite.
> 
>     # onevm create example.vm
> 
>     This results in a good history record...
> 
>     VIRTUAL MACHINE HISTORY
>      SEQ        HOSTNAME REASON           START        TIME       PTIME
>       0          arch02   none  04/16 20:58:58    0d 00:00    0d 00:00
> 
>      <HISTORY_RECORDS>
>        <HISTORY>
>          <SEQ>0</SEQ>
>          <HOSTNAME>arch02</HOSTNAME>
>          <HID>3</HID>
>          <STIME>1334609938</STIME>
>          <ETIME>0</ETIME>
>          <VMMMAD>vmm_kvm</VMMMAD>
>          <VNMMAD>ovswitch</VNMMAD>
>          <PSTIME>1334609938</PSTIME>
>          <PETIME>1334609940</PETIME>
>          <RSTIME>1334609940</RSTIME>
>          <RETIME>0</RETIME>
>          <ESTIME>0</ESTIME>
>          <EETIME>0</EETIME>
>          <REASON>0</REASON>
>        </HISTORY>
>      </HISTORY_RECORDS>
> 
>     # onevm create example.vm ; onevm create example.vm
> 
>     This results in none of the timers being set in the history record for
>     either VM.
> 
>     VIRTUAL MACHINE HISTORY
>      SEQ        HOSTNAME REASON           START        TIME       PTIME
>       0          host02   none               - 15446d 20:5    0d 00:00
> 
>      <HISTORY_RECORDS>
>        <HISTORY>
>          <SEQ>0</SEQ>
>          <HOSTNAME>host02</HOSTNAME>
>          <HID>3</HID>
>          <STIME>0</STIME>
>          <ETIME>0</ETIME>
>          <VMMMAD>vmm_kvm</VMMMAD>
>          <VNMMAD>ovswitch</VNMMAD>
>          <PSTIME>0</PSTIME>
>          <PETIME>0</PETIME>
>          <RSTIME>0</RSTIME>
>          <RETIME>0</RETIME>
>          <ESTIME>0</ESTIME>
>          <EETIME>0</EETIME>
>          <REASON>0</REASON>
>        </HISTORY>
>      </HISTORY_RECORDS>
> 
>     # onevm livemigrate 62 host2 ; onevm livemigrate 62 host01 (both of these
>     fail on purpose)
>     # onevm show 62
>     <snip>
>     STATE               : ACTIVE
>     LCM_STATE           : RUNNING
>     VIRTUAL MACHINE HISTORY
>      SEQ        HOSTNAME REASON           START        TIME       PTIME
>       0          host02   user  04/16 20:58:58    0d 00:02    0d 00:00
>       1          host01   user               - 15446d 21:0    0d 00:00
>       2          host02   user               - 15446d 21:0    0d 00:00
>       3          host02   none  04/16 21:03:51    0d 00:00    0d 00:00
>       4          host02   none               - 15446d 21:0    0d 00:00
>     oneadmin at arch01:~$ onevm livemigrate 62 host02
>     [VirtualMachineMigrate] Wrong state to perform action
> 
>     Chris
> 
>     ---------------------------------------------------------------------
>     This transmission (including any attachments) may contain confidential
>     information, privileged material (including material protected by the
>     solicitor-client or other applicable privileges), or constitute non-public
>     information. Any use of this information by anyone other than the intended
>     recipient is prohibited. If you have received this transmission in error,
>     please immediately reply to the sender and delete this information from
>     your system. Use, dissemination, distribution, or reproduction of this
>     transmission by unintended recipients is not authorized and may be
>     unlawful.
>     _______________________________________________
>     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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: one-unique-name.diff
Type: text/x-diff
Size: 1499 bytes
Desc: not available
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20120417/c38a9c2a/attachment-0002.diff>