Correct, I happened to find it while testing a PR of mine targeted at master.
> On Jul 17, 2018, at 1:30 PM, Rafael Weingärtner <rafaelweingart...@gmail.com> > wrote: > > Correct. I do think the problem here is only in the release notes. > > Just to confirm, you found the problem while testing 4.12 (from master), > right? > > On Tue, Jul 17, 2018 at 4:22 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> > wrote: > >> 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 >> > > > > -- > Rafael Weingärtner
