Re: Inplace upgrading 4.4.x -> 4.5.0

[Steven Haigh <netwiz@crc.id.au>]

[-- Attachment #1.1: Type: text/plain, Size: 2640 bytes --]

On 18/02/2015 11:38 PM, Ian Campbell wrote:
> On Mon, 2015-02-09 at 20:36 +1100, Steven Haigh wrote:
>>> This sounds like a packaging issue -- Debian's packages for example jump
>>> through some hoops to make sure multiple tools packages can be installed
>>> in parallel and the correct ones selected for the currently running
>>> hypervisor.
>>
>> Hmmm - that sounds very hacky :\
> 
> I've been slowly unpicking the Debian patches and upstreaming bits of
> them, I'm not sure if I'll manage to get this stuff upstream though
> since it is a bit more invasive than the other stuff.

Anything that helps out here is a good thing.

>> Hmmm Andrew is correct, the errors are all:
>>
>> ============= xl info ==============
>> libxl: error: libxl.c:5044:libxl_get_physinfo: getting physinfo:
>> Permission denied
> 
> EPERM is essential "tools/hypervisor version mismatch" in most contexts.
> 
> [...]
>> So, this leads me to wonder - as I'm sure MANY people get bitten by this
>> - how to control (at least to shutdown) DomUs after an in-place upgrade?
> 
> You should evacuate the host before upgrading it, which is what I
> suppose most people do as the first step in their maintenance window.
> Evacuation might involve migrating VMs to another host (perhaps as part
> of a pool rolling upgrade type manoeuvre) or just shutting them down.
> 
>> Even if no other functions are implemented other than shutdown, I would
>> call that an acceptable functionality. At least this way, you're not
>> hard killing running VMs on reboot.
> 
> I'd expect that it might be possible to arrange to connect to the VM
> console and shut it down from within, or possibly to use the xenstore
> CLI tools to initiate the shutdown externally.
> 
> After that then you would still end up with some zombie domains since
> after they have shutdown actually reaping them would require toolstack
> actions to talk to the hypervisor and you'd hit the version mismatch.

In large scale organisations (10+ systems), then yes, I'd say you're
probably right. This problem hits those who are smaller than that
however. I could list countless people who have been bitten by this in
the past - the majority of which are small businesses / hobbyists that
don't have the kind of equipment to do any of the above.

The expected upgrade path for those types is "yum -y update && reboot"

As we know, this falls over in a heap - however I don't think it is
beyond the realms of expectation for this to work.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel