[
https://issues.apache.org/jira/browse/CLOUDSTACK-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314467#comment-16314467
]
ASF subversion and git services commented on CLOUDSTACK-10128:
--------------------------------------------------------------
Commit 1d0f2128f62ff32b9cff27f6de1ed711563b656b in cloudstack's branch
refs/heads/master from [~rafaelweingartner]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=1d0f212 ]
[CLOUDSTACK-9025][CLOUDSTACK-10128] solve problems of templates created based
on snapshots (#2315)
The first PR(#1176) intended to solve #CLOUDSTACK-9025 was only tackling the
problem for CloudStack deployments that use single hypervisor types (restricted
to XenServer). Additionally, the lack of information regarding that solution
(poor documentation, test cases and description in PRs and Jira ticket) led the
code to be removed in #1124 after a long discussion and analysis in #1056. That
piece of code seemed logicless (and it was!). It would receive a hostId and
then change that hostId for other hostId of the zone without doing any check;
it was not even checking the hypervisor and storage in which the host was
plugged into.
The problem reported in #CLOUDSTACK-9025 is caused by partial snapshots that
are taken in XenServer. This means, we do not take a complete snapshot, but a
partial one that contains only the modified data. This requires rebuilding the
VHD hierarchy when creating a template out of the snapshot. The point is that
the first hostId received is not a hostId, but a system VM ID(SSVM). That is
why the code in #1176 fixed the problem for some deployment scenarios, but
would cause problems for scenarios where we have multiple hypervisors in the
same zone. We need to execute the creation of the VHD that represents the
template in the hypervisor, so the VHD chain can be built using the parent
links.
This commit changes the method
com.cloud.hypervisor.XenServerGuru.getCommandHostDelegation(long, Command).
From now on we replace the hostId that is intended to execute the “copy
command” that will create the VHD of the template according to some conditions
that were already in place. The idea is that starting with XenServer 6.2.0
hotFix ESP1004 we need to execute the command in the hypervisor host and not
from the SSVM. Moreover, the method was improved making it readable and
understandable; it was also created test cases assuring that from XenServer
6.2.0 hotFix ESP1004 and upward versions we change the hostId that will be used
to execute the “copy command”.
Furthermore, we are not selecting a random host from a zone anymore. A new
method was introduced in the HostDao called
“findHostConnectedToSnapshotStoragePoolToExecuteCommand”, using this method we
look for a host that is in the cluster that is using the storage pool where the
volume from which the Snaphost is taken of. By doing this, we guarantee that
the host that is connected to the primary storage where all of the snapshots
parent VHDs are stored is used to create the template.
Consider using Disabled hosts when no Enabled hosts are found
This also closes #2317
> Template from snapshot not merging vhd files
> --------------------------------------------
>
> Key: CLOUDSTACK-10128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10128
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.10.0.0, 4.9.2.0, 4.5.2.2, 4.9.3.0
> Environment: Production environment running ACS 4.5.2.2, 4.9.2.0,
> 4.9.3.0
> XenServer 6.5
> Primary Storage NFS and ISCSI
> Fresh install running 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10
> Reporter: Marcelo Lima
> Assignee: Rafael Weingärtner
> Priority: Critical
>
> If we have two or more snapshots of a ROOT disk and try to create a template
> from differencial snapshots, CloudStack not merging the vhd files on
> secondary storage.
> Steps to reproduce
> 1. Create virtual machine - OK
> 2. Create a manual snapshot from ROOT volume - OK
> The vhd of first snapshot (snapshot-base) is stored on secondary storage
> correctly
> [root@acs01 6]# ls -l
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> -rw-r--r-- 1 root root 1767191040 Nov 1 12:12
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> [root@acs01 6]# md5sum
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
>
> 240e5e424552d44b5d297895b064beee
> /exports/secondary/snapshots/2/6/011a7650-a13f-4332-8c72-2428a002affc.vhd
> 3. Create a template from snapshot-base - OK
> [root@acs01 6]# ls -l
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>
> -rw-r--r-- 1 root root 1767191040 Nov 1 12:17
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> [root@acs01 6]# md5sum
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
>
> 240e5e424552d44b5d297895b064beee
> /exports/secondary/template/tmpl/2/206/be3311d9-8e59-4240-968d-73d7a6eecfdd.vhd
> This template from snapshot-base boot normally
> 4. Create new file (1GB) on ROOT volume
> 5. Create new snapshot (snapshot-diff) from ROOT volume - OK
> [root@acs01 6]# ls -l /exports/secondary/snapshots/2/6/
> total 2840056
> -rw-r--r-- 1 root root 1767191040 Nov 1 12:12
> 011a7650-a13f-4332-8c72-2428a002affc.vhd <- snapshot-base
> -rw-r--r-- 1 root root 1141019136 Nov 1 12:21
> 1503adaa-4f6e-4f9c-8d80-68663baa86b8.vhd <- snapshot-diff
> 6. Create a template from second snapshot - NOK
> [root@acs01 6]# ls -lh
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
>
> -rw-r--r-- 1 root root 1141019136 Nov 1 12:30
> /exports/secondary/template/tmpl/2/207/4c5c51a1-fcb4-4cc8-8f97-1664a63af262.vhd
> CloudStack not merging snapshot-base and snapshot-diff. Template from second
> snapshot is corrupted because is based just on differential vhd.
> Volume from snapshot work very well
> 1. Create a volume from snapshot-diff - OK
> CloudStack merge two snapshots in one file
> [root@acs01 primary]# ls -l
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> -rw-r--r-- 1 root root 2843030016 Nov 1 12:34
> /exports/primary/70f1db23-cc59-4ec7-b8d4-ed036228593b.vhd
> 2. Download the new volume to check vhd on secondary storage
> [root@acs01 9]# ls -l
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> -rw-r--r-- 1 root root 2843030016 Nov 1 12:35
> /exports/secondary/volumes/2/9/ec6e0f65-bb71-4c91-bac3-287cde2106b7.vhd
> We test on 4.5.2.2, 4.9.2.0, 4.9.3.0 and 4.10. XenServer 6.5 with SP1 and
> XenServer 6.5 with all patches.
> A workaround is create a volume (data-disk) from latest snapshot, create new
> snapshot from data-disk and convert to template.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
