From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: Inplace upgrading 4.4.x -> 4.5.0 Date: Mon, 09 Feb 2015 20:36:29 +1100 Message-ID: <54D87F9D.4090803@crc.id.au> References: <54D7176D.30101@crc.id.au> <441844878.20150209095955@eikelenboom.it> <54D8794C.5050401@crc.id.au> <1423473366.23098.16.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7341357804223678856==" Return-path: In-Reply-To: <1423473366.23098.16.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============7341357804223678856== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HLtBqiqnJU3cNwAVr5MF8mPIPNs6bLp4k" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HLtBqiqnJU3cNwAVr5MF8mPIPNs6bLp4k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/02/2015 8:16 PM, Ian Campbell wrote: > On Mon, 2015-02-09 at 20:09 +1100, Steven Haigh wrote: >> On 9/02/2015 7:59 PM, Sander Eikelenboom wrote: >>> Monday, February 9, 2015, 9:35:33 AM, you wrote: >>> >>>> Hello Steven, >>>> upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. >>> >>>> Please post more details and we'll try to help you figure out what's= >>>> wrong. >>> >>>> Cheers, >>> >>>> Stefano >>> >>>> On Sun, 8 Feb 2015, Steven Haigh wrote: >>>>> Hi all, >>>>> >>>>> I was under the impression that you should be able to do in-place >>>>> upgrades from Xen 4.4 to 4.5 on a system without losing the ability= to >>>>> manage DomUs... >>>>> >>>>> This would support upgrades from running systems from Xen 4.4.x to = 4.5.0 >>>>> - only requiring a reboot to boot into the 4.5.0 hypervisor. >>>>> >>>>> When I try this in practice, I get a whole heap of permission denie= d >>>>> errors and lose control of any running DomUs. >>>>> >>>>> Is there some secret sauce that will allow this to work? >>> >>> You are probably running into a mismatch between the running hypervis= or (4.4) and=20 >>> the now installed toolstack (4.5) .. for instance when trying to shut= down the VM's >>> to do the reboot.=20 >>> (Since the newly installed hypervisor parts are only loaded and run o= n the next boot). >> >> Correct - It is the 4.4 Hypervisor with 4.5 toolstack. After a reboot,= >> all is good. However this causes the problem - once you update the >> packages from 4.4 -> 4.5, you lose the ability to manage any running D= omUs. >=20 > This sounds like a packaging issue -- Debian's packages for example jum= p > through some hoops to make sure multiple tools packages can be installe= d > in parallel and the correct ones selected for the currently running > hypervisor. Hmmm - that sounds very hacky :\ > Otherwise I think the upgrade path is: > * shutdown all VMs (or migrate them away) > * install new Xen + tools > * reboot > * restart domains with new tools. >=20 > I'm afraid that using old tools on a new Xen is not something which is > supported, even in the midst of an upgrade and AFAIK never has been. Th= e > N->N+1->N+2 statement is normally with reference to live migration (i.e= =2E > you can live migrate from a 4.4 system to a 4.5 one). Hmmm Andrew is correct, the errors are all: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xl info =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D libxl: error: libxl.c:5044:libxl_get_physinfo: getting physinfo: Permission denied libxl_physinfo failed. libxl: error: libxl.c:5534:libxl_get_scheduler: getting domain info list: Permission denied host : xenhost release : 3.14.32-1.el6xen.x86_64 version : #1 SMP Sun Feb 8 15:41:07 AEDT 2015 machine : x86_64 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version : 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : (null) xen_pagesize : 4096 platform_params : virt_start=3D0xffff800000000000 xen_changeset : xen_commandline : dom0_mem=3D1024M cpufreq=3Dxen dom0_max_vcpus=3D= 1 dom0_vcpus_pin console=3Dtty0 console=3Dcom1 com1=3D115200,8n1 cc_compiler : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Thu Jan 1 18:19:30 AEDT 2015 xend_config_format : 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xl list =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D libxl: error: libxl.c:669:libxl_list_domain: getting domain info list: Permission denied libxl_list_domain failed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xl dmesg =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D libxl: error: libxl.c:6061:libxl_xen_console_read_line: reading console ring buffer: Permission denied 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? 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. --=20 Steven Haigh Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 --HLtBqiqnJU3cNwAVr5MF8mPIPNs6bLp4k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2H+dAAoJEEGvNdV6fTHcxiEQAIAEwk6JVQdwSGDB0FrnEQXm LwLr2Cqs9XpPsI9YOW2P3/b2L9W2zZHwJNSbDeP3uJdUn1ywgQjjlczMg4prEsvG cRf8jZtpr4BJ2mNOG/hRqAfp68ux3hHX6r/18oryrhnchQbwcz2zjuRjq3H54UPe vYQ3blkYfzNQ7DJuC6mzdnDkJ6Qqto6bJxU6O6Jo4eBnIh6qZAchMP10y8MhPoCc BKBvDqFMIG0MmzKiPwRZpkNlF2x+Mz+YvHY+iDFyr2pac+Cfq63iaiUvbW0dD1D6 sdDlm2PvoAIYyRQ02LVTKNkdeA67bpydSQ+zfHATZ9gjPzj2cP+d5q1h5t5LnnAA LCXCNKkRPHh/JaUVKF0tEa1kkiyn7VQJBS100Svx1CjGboz0q1u/UlMzMJWTscAy gWE/uGNchkSMBQoxAfvCdof8Hz8nHrkkF3gLISmEThKX+VDOdJ3NGOjEbm30wzYA R1HBQqk9CGemwXTI2K6tDkNs9dxO9du5dh7XAMEW4Knw6Pa/ZIp/GOmRRRPZfBEv irtxUntT2UBpD2temqImGh2CbbOAmTMA+XJ40sWFgGI4n5NyWD9xhGdfw3iaN43y dAPX6wjCElbI7iysjq3IANg8iciIbAq7YjusazQsGN8+8b4fsTyu967qHvHxFVSh tznlUMkbcn5jZDbz9HHe =cGeH -----END PGP SIGNATURE----- --HLtBqiqnJU3cNwAVr5MF8mPIPNs6bLp4k-- --===============7341357804223678856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7341357804223678856==--