Cool, if it’s just in master, then that makes it easier. Also, it means we did not have a process issue by introducing enhancement code in between release candidates.
It would mean, however, that our documentation is a bit incorrect if, in fact, it states that that feature exists in 4.11.1. > On Jul 17, 2018, at 1:20 PM, Rafael Weingärtner <rafaelweingart...@gmail.com> > wrote: > > Ok, thanks. I had the impression that we said it was backported to 4.11. > > I will get master and work on it then. > > On Tue, Jul 17, 2018 at 4:12 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> > wrote: > >> I only noticed it in master. The example code I was comparing it against >> was from 4.11.0. I never checked against 4.11.1. >> >>> On Jul 17, 2018, at 1:02 PM, Rafael Weingärtner < >> rafaelweingart...@gmail.com> wrote: >>> >>> Hey Mike, I got the branch 4.11 to start fixing the problem we discussed, >>> but I do not think my commit was backported to 4.11. I mean, I am at >>> "VirtualMachineManagerImpl" and the code is not here. I also checked the >>> commit ( >>> https://github.com/apache/cloudstack/commit/ >> f2efbcececb3cfb06a51e5d3a2e77417c19c667f) >>> that introduced those changes to master, and according to Github, it is >>> only in the master branch, and not in 4.11. >>> >>> I checked the "VirtualMachineManagerImpl" class at the Apache CloudStack >>> remote repository in the 4.11 branch, and as you can see, the code there >> is >>> the “old” one. >>> https://github.com/apache/cloudstack/blob/4.11/engine/ >> orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java >>> >>> I got a little confused now. Did you detect the problem in 4.11 or in >>> master? >>> >>> >>> On Tue, Jul 17, 2018 at 12:27 AM, Tutkowski, Mike < >> mike.tutkow...@netapp.com >>>> wrote: >>> >>>> Another comment here: The part that is broken is if you try to let >>>> CloudStack pick the primary storage on the destination side. That code >> no >>>> longer exists in 4.11.1. >>>> >>>> On 7/16/18, 9:24 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> >> wrote: >>>> >>>> To follow up on this a bit: Yes, you should be able to migrate a VM >>>> and its storage from one cluster to another today using non-managed >>>> (traditional) primary storage with XenServer (both the source and >>>> destination primary storages would be cluster scoped). However, that is >> one >>>> of the features that was broken in 4.11.1 that we are discussing in this >>>> thread. >>>> >>>> On 7/16/18, 9:20 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> >>>> wrote: >>>> >>>> For a bit of info on what managed storage is, please take a look >>>> at this document: >>>> >>>> https://www.dropbox.com/s/wwz2bjpra9ykk5w/SolidFire% >>>> 20in%20CloudStack.docx?dl=0 >>>> >>>> The short answer is that you can have zone-wide managed storage >>>> (for XenServer, VMware, and KVM). However, there is no current zone-wide >>>> non-managed storage for XenServer. >>>> >>>> On 7/16/18, 6:20 PM, "Yiping Zhang" <yzh...@marketo.com> wrote: >>>> >>>> I assume by "managed storage", you guys mean primary >> storages, >>>> either zone -wide or cluster-wide. >>>> >>>> For Xen hypervisor, ACS does not support "zone-wide" primary >>>> storage yet. Still, I can live migrate a VM with data disks between >>>> clusters with storage migration from web GUI, today. So, your statement >>>> below does not reflect current behavior of the code. >>>> >>>> >>>> - If I want to migrate a VM across clusters, but >> if >>>> at least one of its >>>> volumes is placed in a cluster-wide managed >>>> storage, the migration is not >>>> allowed. Is that it? >>>> >>>> [Mike] Correct >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Rafael Weingärtner >> > > > > -- > Rafael Weingärtner
