Open Stack

Hello,

I've just finished implementing the changes to my production environment
and found I needed to do a few more steps. I'm not sure where the
difference between the test and production environments are... maybe it's
because my test environment is virtual and so kvm and qemu detect things
differently or maybe the package juggling in the test environment polluted
the tests. No idea... anyway...

Upon doing an upgrade to the latest mentioned packages, I found that
existing instances could then be hard-rebooted. They weren't able to before
the latest round of packages, so we're off to a good start. Even more, once
hard-rebooted, they could even be migrated.

But existing instances could not be migrated, soft-rebooted, paused,
suspended, etc. Once hard-rebooted, all of those things worked.

I was just about to cut my losses and consider that acceptable but thought
I'd dig into things further. I started reviewing all bug reports mentioned
in this thread and closely read the SRU Justification here:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1374622

I then configured /etc/libvirt/qemu.conf with:

allow_incoming_qemukvm = 1

Upon trying a migration again, I got an error about a
missing pxe-virtio.rom.12.04. This was also mentioned in this bug report:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1291321

So I copied the /usr/share/qemu/pxe-virtio.rom file from a compute node
that wasn't yet upgraded as /usr/share/qemu/pxe-virtio.rom.12.04 on the
upgraded node (and the destination node of the migration). I rebooted
libvirt-bin and sure enough the migration worked!

Similarly, soft-rebooting et al also works.

And even better, once live-migrated, the instance takes on the new machine
type of "pc-i440fx-trusty" so it's now compatible with 14.04.

So as far as I can tell, I'm in good shape. I've tested a bunch of
scenarios (launching, migrating, rebooting, etc) and everything seems OK.
I'll give it a few days to see if any users run into issues.

Thanks,
Joe


On Tue, Nov 18, 2014 at 12:44 PM, Joe Topjian <joe at topjian.net> wrote:

> Oops - I just noticed the initial libvirt packages I pasted were wrong...
> too early in the morning, I guess.
>
> I started out with:
>
> libvirt0 1.2.2-0ubuntu13.1.2~cloud0
> libvirt-bin 1.2.2-0ubuntu13.1.2~cloud0
> python-libvirt 1.2.2-0ubuntu1~cloud0
>
> And then moved to:
>
> libvirt-bin 1.2.2-0ubuntu13.1.6~cloud2
> libvirt0 1.2.2-0ubuntu13.1.6~cloud2
> python-libvirt 1.2.2-0ubuntu2~cloud0
>
> Joe
>
> On Tue, Nov 18, 2014 at 10:49 AM, Joe Topjian <joe at topjian.net> wrote:
>
>> Hi Daniele,
>>
>> Here are the packages I started with in my test environment and what the
>> initial instances were based on:
>>
>> dpkg -l | grep qemu
>> ii  kvm
>>  1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.19
>> ii  qemu-common                      1.0+noroms-0ubuntu14.19
>>
>> ii  qemu-kvm                         1.0+noroms-0ubuntu14.19
>>
>> ii  qemu-utils                       1.0+noroms-0ubuntu14.19
>>
>>
>> dpkg -l | grep libvirt
>> ii  libvirt-bin                      1.2.2-0ubuntu13.1.6~cloud2
>> ii  libvirt0                         1.2.2-0ubuntu13.1.6~cloud2
>> ii  nova-compute-libvirt             1:2014.1.3-0ubuntu1~cloud0
>> ii  python-libvirt                   1.2.2-0ubuntu2~cloud0
>>
>> And here's the result after I upgraded the packages using the Icehouse
>> cloud archive:
>>
>> dpkg -l | grep qemu
>> ii  ipxe-qemu
>>  1.0.0+git-20131111.c3d1e78-2ubuntu1~cloud0
>> ii  qemu-common                      2.0.0+dfsg-2ubuntu1.6~cloud0
>> ii  qemu-keymaps                     2.0.0+dfsg-2ubuntu1.6~cloud0
>> ii  qemu-kvm                         2.0.0+dfsg-2ubuntu1.6~cloud0
>> ii  qemu-system-common               2.0.0+dfsg-2ubuntu1.6~cloud0
>> ii  qemu-system-x86                  2.0.0+dfsg-2ubuntu1.6~cloud0
>> ii  qemu-utils                       2.0.0+dfsg-2ubuntu1.6~cloud0
>>
>> dpkg -l | grep libvirt
>> ii  libvirt-bin                      1.2.2-0ubuntu13.1.6~cloud2
>> ii  libvirt0                         1.2.2-0ubuntu13.1.6~cloud2
>> ii  nova-compute-libvirt             1:2014.1.3-0ubuntu1~cloud0
>> ii  python-libvirt                   1.2.2-0ubuntu2~cloud0
>>
>> The libvirt packages (1.2.2-0ubuntu13.1.6~cloud2), I think, are the most
>> important part to bridge everything together. These new versions for both
>> 12.04 and 14.04 included the compatibility for vms / instances created with
>> older qemu versions.
>>
>> From the tests I've done so far, everything looks good. I'd love to hear
>> if you, or others, are still seeing issues after upgrading to the latest
>> packages.
>>
>> Thanks,
>> Joe
>>
>> On Tue, Nov 18, 2014 at 10:23 AM, Daniele Venzano <
>> daniele.venzano at eurecom.fr> wrote:
>>
>>>  Hi,
>>>
>>> Which versions did you test, exactly?
>>>
>>> Here I'm seeing these in APT:
>>> 1.0.50-2012.03-0ubuntu2
>>> 1.0.50-2012.03-0ubuntu2.1
>>> 1.5.0+dfsg-3ubuntu5.4~cloud0 (havana ubuntu cloud repo)
>>> 2.0.0+dfsg-2ubuntu1.6~cloud0 (icehouse ubuntu cloud repo)
>>>
>>> Thanks,
>>> Daniele
>>>
>>>
>>> On 11/17/14 21:30, Joe Topjian wrote:
>>>
>>> Thanks, Felipe!
>>>
>>>  I was going to wait until I did some more testing, but since I'm on
>>> this topic:
>>>
>>>  I have done some preliminary tests with the latest libvirt packages
>>> from Ubuntu (available in both 12.04 and 14.04). The tests were done in a
>>> 12.04 Icehouse environment that supports live migration. I created several
>>> instances using the stock qemu and libvirt packages and then upgraded both
>>> sets of packages.
>>>
>>>  Hard rebooting, live migration, and hard reboot of live-migrated
>>> instances were all successful.
>>>
>>>  I still want to run through the tests a few more times (especially
>>> migrating to 14.04 hosts), but it looks as though the latest Ubuntu
>>> packages resolve any backwards compatibility issues.
>>>
>>>
>>> On Mon, Nov 17, 2014 at 9:12 PM, Felipe Reyes <freyes at tty.cl> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Tue, 21 Oct 2014 13:42:24 -0600
>>>> Joe Topjian <joe at topjian.net> wrote:
>>>>
>>>> > > I wonder if the qemu update issues are in the realm of the OpenStack
>>>> > > project.
>>>> > > Since they are provided / packaged by the distro's.
>>>> > > Maybe people from Ubuntu & Redhat (which I would be interested in ;)
>>>> > > reading this could give some suggestions...
>>>> > >
>>>> >
>>>> > I'd really appreciate someone from Ubuntu or Redhat clarifying this
>>>> > situation.
>>>> >
>>>> There is some work on Ubuntu's side to get a clean migration path, see:
>>>> https://lists.ubuntu.com/archives/ubuntu-server/2014-October/006983.html
>>>>
>>>> https://lists.ubuntu.com/archives/ubuntu-server/2014-November/006988.html
>>>>
>>>> Best Regards,
>>>>
>>>> PS: I'm not involved in any way with that development, just read about
>>>> it :)
>>>> --
>>>> Felipe Reyes (GPG:0x9B1FFF39)
>>>> http://tty.cl
>>>> lp:~freyes | freyes at freenode | freyes at github
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing listOpenStack-operators at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141126/aabc59b5/attachment-0001.html>