Yep. Migration is just a resize (from flavor to same flavor). Instance
disk transferred by scp/rsync.
On 10/09/2014 05:36 AM, Joe Topjian wrote:
Ah - so it sounds like the issue might be local to just non-live/cold
migration? The type that requires SSH key exchange? That's what
resizing uses behind the scenes, so it makes sense that it would fail
as well.
On Wed, Oct 8, 2014 at 8:30 PM, George Shuklin
<george.shuk...@gmail.com <mailto:george.shuk...@gmail.com>> wrote:
We using Havana, with raw images and non-live migration (rsync/scp
on halted VMs).
Migration happens, but during instance start nova-compute fail to
find image locally and in glance.
I saw Icehouse patch to made a copy of image from original host
but it looks too slow for me (for the raw disk of instance booted
from snapshot it gonna be double migration time).
On Oct 8, 2014 8:19 PM, "Joe Topjian" <j...@topjian.net
<mailto:j...@topjian.net>> wrote:
We just ran some tests on our production Icehouse environment
and can confirm that:
* Snapshotting an instance based on a deleted image works
* Snapshotting an instance based on a public-turned-private
image works
* Block migration of an instance based on a deleted image works
This environment does not utilize _base images.
We didn't do any resizing tests as we do not have our
environment configured to allow it. At the moment, if a user
tries resizing they receive an error message. It's not a
friendly way to disable an action so we plan on just removing
the option from Horizon altogether.
We also tested the following with an older Grizzly environment
that supports live migration:
* Snapshotting an instance based on a deleted image (and base
image) works
* Live migrating an instance based on a deleted image (and
base image) works
Resizing is not supported in this environment as well.
I'm curious about your environment where these actions are
failing for you?
Thanks,
Joe
On Tue, Oct 7, 2014 at 3:03 PM, George Shuklin
<george.shuk...@gmail.com <mailto:george.shuk...@gmail.com>>
wrote:
Yep, this bug is still actual. Resize, migration and so on
does not work if original image is deleted. And 'I will
never remove any public image' will not helps, because if
user restore instance from snapshot and remove snapshot it
will cause error too. That looks stupid in the light of
(our) raw disk format, where 'base copy' just never used.
Error is harmless and can be fixed by
nova reset-state --active UUID
(optionally)
nova stop UUID
nova start UUID
But it's still annoying because user can not fix it own
instance without administrator intervention.
We have plans to fix it for havana (it cause disturbance
for as and inconvenience for our customers), but fix will
not be accepted by upstream (they drops upstream support
ASAP), so I think we should switch to old-style maillist
based patch RFC.
On 10/07/2014 10:16 PM, Jan van Eldik wrote:
Hi,
Please note the issue reported in
https://bugs.launchpad.net/nova/+bug/1160773: "Cannot
resize instance if base image is not available"
AFAIK it is still the case that instances cannot be
resized or migrated
once the image from which it has been created has been
deleted.
cheers, Jan
On 10/07/2014 09:01 PM, Abel Lopez wrote:
Right, and I think the best thing about marking a
deprecated image private is that
new instances can’t select that image unless the
tenant is an image-member of it.
So if a specific tenant has some “real valid” need
to use the old version (I can’t imagine why), they
could find it in “Project Images” instead of “Public”.
On Oct 7, 2014, at 11:57 AM, Sławek Kapłoński
<sla...@kaplonski.pl <mailto:sla...@kaplonski.pl>>
wrote:
Hello,
Yes, I agree that this is not big problem when
there is info "Image not found"
in horizon but I saw this discussion and I
thought that I will ask about that
:) It would be nice to have some other info
like for example: "Image 1
(archived)" or something like that :)
---
Best regards
Sławek Kapłoński
sla...@kaplonski.pl <mailto:sla...@kaplonski.pl>
Dnia wtorek 07 październik 2014 18:21:13 piszesz:
I've never worried about "Image not
Found", as its only a UI concern. IMO
it lets the users know something has
changed. Totally optional, and the
same effect can be gained by just renaming
it -OLD and leaving it public.
At some point, it still needs to be removed.
On Tuesday, October 7, 2014, Sławek
Kapłoński <sla...@kaplonski.pl
<mailto:sla...@kaplonski.pl>> wrote:
Hello,
I use Your solution and I made old
images as private in such change but
then
there is one more problem: all
instances spawned from that old images are
have
in horizon info about image: "not found".
Do You maybe know how to solve that?
---
Best regards
Sławek Kapłoński
sla...@kaplonski.pl
<mailto:sla...@kaplonski.pl>
<javascript:;>
Dnia wtorek, 7 października 2014
10:05:57 Abel Lopez pisze:
You are correct, deleted images
are not deleted from the DB, rather
their
row has ‘deleted=1’, so specifying
the UUID of another image already in
glance for a new image being
upload will end in tears.
What I was trying to convey was,
when Christian is uploading a new
image
of
the same name as an existing
image, the UUID will be different.
IMO, the
correct process should be:
1. Make desired changes to your image.
2. Rename the existing image (e.g.
Fedora-20-OLD)
3. (optional) Make the old image
private ( is-public 0 )
4. Upload the new image using the
desired name (e.g. Fedora-20 or like
Fedora-20-LATEST )
Obviously I assume there was
testing for viability of the image
before
it
was uploaded to glance.
For more information, be sure to
catch my talk on Tuesday 9am at the
summit.
On Oct 7, 2014, at 9:58 AM, George
Shuklin <george.shuk...@gmail.com
<mailto:george.shuk...@gmail.com>
<javascript:;>> wrote:
As far as I know, it is not
possible to assign uuid from
deleted image
to
the new one, because deleted
images keeps their metadata in
DB.>
On 09/26/2014 04:43 PM, Abel
Lopez wrote:
Glance images are
immutable. In order to
update it, you should do as
you
are doing, but then rename
the old image, then upload
the updated
one.
Take note of the UUID as well.
On Friday, September 26,
2014, Christian Berendt <
bere...@b1-systems.de
<mailto:bere...@b1-systems.de>
<javascript:;>>
wrote: I'm trying to
update the contents of an
image, but it looks
like
it is not working at all.
First I upload a test image:
---snip---
# dd if=/dev/urandom
of=testing.img bs=1M count=10
# glance image-create
--disk-format raw
--container-format bare
--name
TESTING --file testing.img
---snap---
Now I want to overwrite
the contents of this image:
---snip---
# dd if=/dev/urandom
of=testing.img bs=1M count=20
# glance image-update
--file testing.img TESTING
---snap---
After this call the size
of the image is still the
same like before
(10485760 bytes).
I do not have issues in
the logfiles of glance-api and
glance-registry.
What am I doing wrong?
Is it not possible to
update the contents of an
image?
Christian.
--
Christian Berendt
Cloud Solution Architect
Mail:
bere...@b1-systems.de
<mailto:bere...@b1-systems.de>
<javascript:;>
B1 Systems GmbH
Osterfeldstraße 7 / 85088
Vohburg /
http://www.b1-systems.de
GF: Ralph Dehner /
Unternehmenssitz: Vohburg
/ AG: Ingolstadt,HRB
3537
_______________________________________________
OpenStack-operators
mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
<javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators
mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
<javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
<javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
