Re: [Xen-devel] Inplace upgrading 4.4.x -> 4.5.0

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.
> 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.

Ian.


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