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" wrote:
To follow up on this a bit: Yes, you should be able to migrate a VM and its
s
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 th
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-
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 state
Awesome! Thanks for your inputs. I will work on them, and as soon as I have
something I will ping you.
On Mon, Jul 16, 2018 at 8:26 PM, Tutkowski, Mike
wrote:
> Yeah, I just meant that was a workaround. As you pointed out, that
> workaround doesn’t make use of the migrateVirtualMachineWithVolume
Yeah, I just meant that was a workaround. As you pointed out, that workaround
doesn’t make use of the migrateVirtualMachineWithVolume API command, though.
On 7/16/18, 5:23 PM, "Rafael Weingärtner" wrote:
Thanks for the answers Mike. I will not be able to do it today, but I will
manage t
Thanks for the answers Mike. I will not be able to do it today, but I will
manage to do it this week. There is only one last doubt.
[Mike] At least for KVM, you can shut the VM down and perform an offline
migration
of the volume from managed storage to non-managed storage. It’s possible we
may
sup
- So, managed storage can be cluster and zone wide. Is that correct?
[Mike] Correct
- 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
I think I understand the confusion here.
Rafael’s code was put into 4.11.1, but not into the initial release candidate
(RC). In fact, the most recent version of 4.11 that has been released is
4.11.1. Somehow Rafael’s code (which is an enhancement) was merged into 4.11
during the RC process. Thi
Thanks for your feedback Mike. I actually did not want to change this
“migrateVirtualMachineWithVolume” API method. Everything started when we
wanted to create a feature to allow volume placement overrides. This means,
allowing root admins to place/migrate the volume to a storage pool that
might no
For your feature, Rafael, are you trying to support the migration of a VM that
has local storage from one cluster to another or is intra-cluster migration of
local storage sufficient?
There is the migrateVolume API (you can pass in “live migrate” parameter):
http://cloudstack.apache.org/api/api
Actually, I think I answered both of your questions with these two prior
e-mails. Please let me know if you need further clarification. Thanks!
On 7/16/18, 2:17 PM, "Tutkowski, Mike" wrote:
Allow me to correct what I said here:
“If getDefaultMappingOfVolumesAndStoragePoolForMigrati
Allow me to correct what I said here:
“If getDefaultMappingOfVolumesAndStoragePoolForMigration is invoked, we
silently ignore the (faulty) input (which is a new storage pool) from the user
and keep the volume in its same managed storage pool (the user may wonder why
it wasn’t migrated if they d
Let me answer the questions in two separate e-mails.
This answer deals with what you wrote about this code:
> if (destPool.getId() == currentPool.getId()) {
> volumeToPoolObjectMap.put(volume, currentPool);
> } else {
> throw new CloudRuntimeException("Currently, a volume
Probably a lack of attention of the people writing the release note. It
happens in manual processes.
On Mon, Jul 16, 2018 at 4:46 PM, Yiping Zhang wrote:
> Why is it listed as fixed in 4.11.1.0 in the release note, If the code
> only exist in 4.11.2?
>
>
>
> On 7/16/18, 12:43 PM, "Tutkowski, Mi
I should be able to do so soon. I’ve been in meetings all day. I’ll try to
investigate this before my next meeting starts.
On 7/16/18, 1:45 PM, "Rafael Weingärtner" wrote:
Yes, that is what happened. I also followed this principle. That is why I
create the PR against master, but I think
Why is it listed as fixed in 4.11.1.0 in the release note, If the code only
exist in 4.11.2?
On 7/16/18, 12:43 PM, "Tutkowski, Mike" wrote:
OK, as Rafael noted, looks like it’s in 4.11.2. My regression tests were
run against 4.11.1. I thought we only allowed bug fixes when going to a ne
Yes, that is what happened. I also followed this principle. That is why I
create the PR against master, but I think people are not following this.
Mike, can you provide me some feedback regarding those two inquiries? Then,
we can fix this quickly.
On Mon, Jul 16, 2018 at 4:42 PM, Tutkowski, Mike
OK, as Rafael noted, looks like it’s in 4.11.2. My regression tests were run
against 4.11.1. I thought we only allowed bug fixes when going to a new RC, but
it appears we are not strictly enforcing that rule.
On 7/16/18, 1:40 PM, "Tutkowski, Mike" wrote:
When I ran my suite of tests on 4.1
When I ran my suite of tests on 4.11.1, I did not encounter this issue. Also,
looking at the code now, it appears this new code is first in 4.12.
On 7/16/18, 1:36 PM, "Yiping Zhang" wrote:
Is this code already in ACS 4.11.1.0?
CLOUDSTACK-10240 is listed as fixed in 4.11.1.0,
It is in 4.11.2.0.
It was first added to 4.12, and then back ported. I am now waiting for
Mike's feedback to proceed with the fix for the problem he found.
On Mon, Jul 16, 2018 at 4:36 PM, Yiping Zhang wrote:
>
> Is this code already in ACS 4.11.1.0?
>
> CLOUDSTACK-10240 is listed as fixed in 4.
Is this code already in ACS 4.11.1.0?
CLOUDSTACK-10240 is listed as fixed in 4.11.1.0, according to release note
here,
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/ja/master/fixed_issues.html,
but in the JIRA ticket itself, the "fixed version/s" field says 4.12.
We are
Hi all - if you're interested in the topic, Rohit has written a blog about it
here:
https://www.shapeblue.com/secure-live-kvm-vm-migration-with-cloudstack-4-11-1/
Best regards,
steve.ro...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Ok, I see what happened there with the migration to cluster. When I re-did
the code I did not have this case. And therefore, in the old code, I was
not seeing this use case (convoluted code, lack of documentation, and so
on; we all know the story). I will fix it.
Regarding the managed storage issu
24 matches
Mail list logo
