incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tamas Monos (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-531) Potential disaster with template-cleanup enabled!
Date Fri, 23 Nov 2012 14:58:58 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503216#comment-13503216
] 

Tamas Monos commented on CLOUDSTACK-531:
----------------------------------------

I've investigated it further and found out that my systemVMs were destroyed because the Volumes
table had two entries for a system VM with the SAME volume name and different templates.

200 |         NULL |          31 |         0 | ROOT-31 | 5e10aa83-828e-4c44-9237-a8d96f358706
| 2097152000 | /Watford/iscsi_0 | ROOT-31 |      1 |              1 | NULL       | NULL  
 | ROOT        | VMFS      |                6 |           8 | NULL                       |
          1 | 
201 |         NULL |          31 |         0 | ROOT-31 | 0cd93f08-ce1e-4535-a778-744cbed0995f
| 2097152000 | /Watford/iscsi_1 | ROOT-31 |      1 |              1 | NULL       | NULL  
 | ROOT        | VMFS      |                6 |         226 | NULL                       |
          1 | 

The clean-up script went for template 8 to destroy, but had the same volume name so it wiped
out the ROOT-31 volume which killed the actual systemVM with new template.
>From here it was a proper VM destroy scenario, shut-down, delete disk...
After this the manager should have re-deployed a system VM for sec storage as the system did
not have one but did not.


                
> Potential disaster with template-cleanup enabled!
> -------------------------------------------------
>
>                 Key: CLOUDSTACK-531
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-531
>             Project: CloudStack
>          Issue Type: Bug
>          Components: Template
>    Affects Versions: 4.0.0
>            Reporter: Tamas Monos
>            Priority: Blocker
>
> Hi,
> I've done an upgrade from 3.0.2 -> 4.0.0.
> All went OK with some workarounds:
> 1. Add new vmware template to CS with name systemvm-vmware-4.0 (I have re-imported it)
> 2. Wait till the template is downloaded and installed successfully
> 3. Look up id of this template in DB (Name should match the input provided in step
> mysql> select id from `cloud`.`vm_template` where name = 
> mysql> 'systemvm-vmware-4.0' and removed is null;
> 4. Update template type to SYSTEM
> mysql> update `cloud`.`vm_template` set type='SYSTEM' where id = 
> mysql> <id-from-step3>;
> 5. Update template Id for all system Vms
> mysql> update `cloud`.`vm_instance` set vm_template_id = <id-from-step3> 
> mysql> where type <> 'User' and hypervisor_type = 'VMware';
> I was very happy as the platform was just working fine. Then I've enabled "storage.template.cleanup.enabled".
This resulted in destruction of my running(!!!) systemVMs.
> Then the management server started telling me that the Zone is not ready for secondary
storage...
> I tried to add a new one which failed. I've removed the current one and tried to recreate
it, failed.
> Management server logs will follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message