Re: [Xen-API] XCP 1.6b3 to 1.6b4 Rolling Pool Update not working
Hi Alan, Thanks for the attention on this guys, however I am still curious... If the XenCenter wizard cannot be used to perform a rolling pool upgrade, how does one do it? you should be able to perform it with the good old way, upgrading the master by evacuating vm running on it and then inserting the XCP 1.6 cd and rebooting. The CD should detect the current installation and propose to upgrade it. Then you evacuate VMs on slave, reboot with CD, upgrade and go on with this process. Hope this helps, Denis Thanks, Alan On 20/11/2012, at 2:50 AM, Mike McClurg mike.mccl...@citrix.com wrote: On 19/11/12 12:47, Lars Kurth wrote: On 19/11/2012 11:55, Mike McClurg wrote: The XCP 1.6 relnotes were copied from the XenServer 6.1 relnotes. This was basically a direct copy, just changing XenServer to XCP. The notes referring to rolling pool upgrade and XenCenter should be removed. Mike It wasn't c complete copy, but we may have not removed entries that are not applicable when going through the XS 6.1 notes. I can see the following entries referring to rolling pool upgrade: liRHEL 4.5 guests may crash when using the Rolling Pool Upgrade Wizard. Before upgrading a XCP host, you must shut down RHEL 4.5 ^^ remove the word Wizard, and change to when performing a rolling pool upgrade. guests. [CA-88618]/li liIf the Rolling Pool Upgrade Wizard discovers storage that is detached and cannot be reattached, it will fail (even when no VMs are using the storage). Users should either fix the access to the storage repository or remove it from the XCP pool before restarting the wizard. [CA-72541]/li ^^^ Remove this bullet. liRolling Pool Upgrade should bnot/b be used with Boot from SAN environments. /li ^^^ Okay here. liWhen installing XCP from a network repository (including when using the XenCenter Rolling Pool Upgrade wizard), you must configure the DHCP ^^^ Remove this parenthetical. Rest of the bullet is fine. server to provide the ttdomain-name/tt option, otherwise DNS will not work correctly, which can lead to a failed installation. [CA-74082]/li Which one(s) should be removed? From the thread it sounds like the last one. If you let me know, I will take them out The above changes should be all we need to make. Thanks Lars! Mike ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api -- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-API] XcP 1.6 beta4 61549c
Hi all, Is there no updates on that because there is no target dates, or is it a communication issue? I must say that with relatively poor deadlines communication its hard to justify and present XCP as a reliable technology in project/company :( Regards, S. On Mon, Nov 12, 2012 at 8:50 PM, SpamMePlease PleasePlease spankthes...@gmail.com wrote: Also, what's current delivery date target for 1.6 final version? I suppose I am not the only person holding back my project until the release ;) Regards, S. On Mon, Nov 12, 2012 at 8:15 PM, Melvin B. melvi...@videotron.ca wrote: Hi, What is the release note for XcP 1.6 beta4 61549c, what are the fix/change made from beta3. Thank you. ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-API] several questions
On 20/11/12 16:22, marc poll garcia wrote: We’re so glad for that quick answer, If we finally choose the XCP 1.6 version and it becomes “Final release”, we should have to reinstall and delete all data on our server, or it will be an update to change the version? I mean, as you guess, our production server we can’t be stopped for a long time and we have to warn our costumers before. We are worried that If we choose the beta release for our systems we wouldn't be able to change it and we need to know how to make it the “final release” in the future. You will be able to upgrade from 1.6 beta to 1.6 final, but I would advise against putting the beta version on your production servers. The final version of XCP 1.6 will be coming out soon, so I would recommend you wait for that. Mike Many thanks Marc Poll Technical Area– *Serveis**Web* * * http://www.serveisweb.com http://www.serveisweb.com/ http://blog.serveisweb.com http://blog.serveisweb.com/ http://www.ticketday.es http://www.ticketday.com Tel. 902 010 664 - Tel. Int. +34 972 010 550 tel:%2B34%20972%20010%20550 Fax 902 510 664 - Fax Int. +34 972 010 555 tel:%2B34%20972%20010%20555 Descripción: green Please, consider the environment before printing this email. LEGAL NOTICE SW Hosting Communications Technologies, SL informs you that this message is intended exclusively for its addressee and contains confidential and / or sensitive information subject to professional secrecy and protected by the current legislation. If you are not the intended recipient, we notify you that the reading, use, disclosure, reproduction, distribution, printing and / or copy of this communication, information and / or any attachments to it are strictly prohibited by law. If you have received this message by mistake, please notify it to us immediately replying to the sender of the message and then delete it with all the attachments if any. *De:*Rushikesh Jadhav [mailto:2rushike...@gmail.com] *Enviado el:* martes, 20 de noviembre de 2012 8:49 *Para:* marc poll garcia *CC:* xen-api@lists.xen.org *Asunto:* Re: [Xen-API] several questions Hi Marc, Many of us use Xen for production and you can certainly use it. XCP1.6 is a beta release which would mostly make itself as Final release. If you want to try out then use XCP1.1 which a stable release but its quite old. As far as DomU storage, if you dont have SAN then use local storage which is ext3. On Mon, Nov 19, 2012 at 11:58 PM, marc poll garcia mp...@serveisweb.com mailto:mp...@serveisweb.com wrote: Hi We’re actually deploying a new Xen plataform for our bussiness, and we thought about several questions trying to get the best performance. Wich is the best partition system and most stable for our DomU? Normal ext3 or on lvm? We want to install the distro XCP 1.6 but we know that it is actually on beta release, is it dangerous for a us to deploy a production system. Many thanks in advance for your help. Regards. ___ Xen-api mailing list Xen-api@lists.xen.org mailto:Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-API] importing XCP 1.1 vm installed template into xcp 1.6 beta
Hi Burnie, When you install a VM, the template is cloned, and the is-template flag is set to false. If there is a 'disks' key in the other-config, then vm-install will create disks as specified. If the template has VDIs attached, then those will be copied at attached to the new VM. Thanks for you answer. So there is no difference between a VM, a template with attached VDI (shown with a blue icon in XenCenter), and a template without attached VDI (shown in yellow in XenCenter). Well, the difference between a default template and a custom template is very subtle. If you really want to see the difference in XC, you could try this: # make a custom template a default template (yellow) xe template-param-set uuid=uuid other-config:default_template=true # make a default template a custom template (blue) xe template-param-remove uuid=uuid param-name=other-config param-key=default_template thanks a lot for your input. It helped me again today. I had a strange case today with a vm having the following line other-config line : other-config (MRW): instant: true; vgpu_pci: ; mac_seed: ea83543a-3265-11e2-a512-1eb79f66b6da; install-methods: cdrom; default_template: false; install-repository: cdrom In the template definition, the default_template param is set to false, but it is still showing in the default template (blue one) in xencenter. Once I use the command line you highlighted and remove the param altogether, everything is fine again. So having the default_template set to false is not enough. Cheers, Denis -- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
[Xen-API] Lost all slaves in pool on XCP 1.6 beta4 after reboot of master
It is find once shutdown all master and slaves servers and reboot. All slaves failed to join the pool and reported that the host was deleted from the master's database. -- Best Regards, Philip *E**mail :* pip.c...@gmail.com ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
[Xen-API] How does dom0 communicate with domUs in HVM of Xen?
Hi all, I have already known that it works by event channel, but what's the detailed mechanism? Who can give the procedure when there is a incinterface calling. Thx Cody ___ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-API] XCP 1.6 BETA problem with pool-dump-database
I also find that if restart the pool (which means I shutdown all master and slaves then reboot all) all slaves will failed to join the pool any more. it will reported the slaves are deleted from the master. and it is unable to recover that and the only resolution I find is to reinstall the XCP in fresh clean mode (do not create local file repos during the setup) then rejoin the master from pool. The workaround now I have is to keep the master on otherwise it will be disaster. On Fri, Nov 16, 2012 at 3:00 PM, Black Bird blackbird1...@gmail.com wrote: I'm still struggling with this issue, but have observed something interesting. The command executes correctly on the pool master (xen3v3), and fails on a slave (xen2) with the 'database not in memory' error. Following is the xensource.log file on the pool master in both cases. -- successful attempt from master. Log on master -- Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi||cli] xe pool-dump-database password=null file-name=pool-dump-database.20121116173600 username=root Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|session.login_with_password D:2d839a80985d|xapi] Session.create trackid=8e34ba23e24c9883b5c413ddfcb356bc pool=false uname=root is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49 Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|task.create D:ebb96e910762|taskhelper] task dump database R:be1da62787ce (uuid:35f0640e-c59a-5f2b-f5e9-a6e869f2) created (trackid=8e34ba23e24c9883b5c413ddfcb356bc) by task D:ebb96e910762 Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10238 INET 0.0.0.0:80||taskhelper] task dump database R:be1da62787ce forwarded (trackid=8e34ba23e24c9883b5c413ddfcb356bc) Nov 16 17:36:03 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|session.logout D:7b78ff9cc719|xapi] Session.destroy trackid=8e34ba23e24c9883b5c413ddfcb356bc failed attempt from slave. Log on master Nov 16 17:41:08 xen3v3 xapi: [debug|xen3v3|11148 UNIX /var/xapi/xapi||dummytaskhelper] task dispatch:event.from D:f31d73627b1e created by task D:1f9945cc5399 Nov 16 17:41:10 xen3v3 xapi: [debug|xen3v3|11149 INET 0.0.0.0:80||dummytaskhelper] task dispatch:session.get_uuid D:c0b914428578 created by task D:ee2a926fc137 Nov 16 17:41:10 xen3v3 xapi: [debug|xen3v3|11149 INET 0.0.0.0:80|dispatch:session.get_uuid D:c0b914428578|api_readonly] session.get_uuid Nov 16 17:41:10 xen3v3 xapi: [ info|xen3v3|11150 INET 0.0.0.0:80||cli] xe pool-dump-database password=null file-name=pool-dump-database.20121116174110 username=root Nov 16 17:41:11 xen3v3 xapi: [ info|xen3v3|11150 INET 0.0.0.0:80|task.create D:a7fff784ed18|taskhelper] task dump database R:b2185135d308 (uuid:6d6d8e2c-df90-8cb3-1603 -698c87ec4a6c) created (trackid=9c40424ccae8e6ab343a904ecd1a7f4c) by task D:a7fff784ed18 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11150 INET 0.0.0.0:80||cli] /pool/xmldbdump?session_id=OpaqueRef:72f48933-ffd3-f6de-bc27-6d71f38e9777task_id=OpaqueRef:b218 5135-d308-c183-1b21-5eb561db5511 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11151 INET 0.0.0.0:80||dummytaskhelper] task dispatch:session.slave_login D:b2b15de6d447 created by task D:631b2c68a809 Nov 16 17:41:11 xen3v3 xapi: [ info|xen3v3|11151 INET 0.0.0.0:80|session.slave_login D:c38111cf7aa1|xapi] Session.create trackid=398737a9788c502c00dda1747cffb792 pool= true uname= is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11151 INET 0.0.0.0:80|session.slave_login D:c38111cf7aa1|mscgen] xapi=xapi [label=methodCallmethodNamesession.get_uuid/methodNameparamsparamvalueOpaqueRef:d021831a-5298-5975-9960-0c10862a11ad/value/paramparamvalueOpaqueRef:d021831a-5298-5975-9960-0c10862a11ad/value/param/params/methodCall]; Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|4 UNIX /var/xapi/xapi||xapi] Set threads number soft limit to 67.351919 with 0.334173 confidence and 0.984833 tolerance, the next tweak will be 60.00 seconds away at the earliest. Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11152 UNIX /var/xapi/xapi||dummytaskhelper] task dispatch:session.get_uuid D:c4cd084c3e8c created by task D:c38111cf7aa1 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11152 UNIX /var/xapi/xapi|dispatch:session.get_uuid D:c4cd084c3e8c|api_readonly] session.get_uuid Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11153 INET 0.0.0.0:80||dummytaskhelper] task dispatch:pool.audit_log_append D:2f3681049c6c created by task D:631b2c68a809 Nov 16 17:41:11 xen3v3 xapi: [ info|xen3v3|11153 INET 0.0.0.0:80|dispatch:pool.audit_log_append D:2f3681049c6c|taskhelper] task pool.audit_log_append R:36a9cfe6d24e (uuid:ba7dfdb3-64dd-0d7b-6100-2f13c51cf949) created
Re: [Xen-API] XCP 1.6 BETA problem with pool-dump-database
Sounds like a different problem. I shut down and restart the pool regularly and the slave/s reconnect normally. Sometimes a slave fails to see the master due to some network glitch, and the only workaround is to reboot the slave after which the pool is reconstituted. You didn't mention the XCP version. My pool is at 1.6Beta2. On Thu, Nov 22, 2012 at 1:53 PM, Philip Chan pip.c...@gmail.com wrote: I also find that if restart the pool (which means I shutdown all master and slaves then reboot all) all slaves will failed to join the pool any more. it will reported the slaves are deleted from the master. and it is unable to recover that and the only resolution I find is to reinstall the XCP in fresh clean mode (do not create local file repos during the setup) then rejoin the master from pool. The workaround now I have is to keep the master on otherwise it will be disaster. On Fri, Nov 16, 2012 at 3:00 PM, Black Bird blackbird1...@gmail.com wrote: I'm still struggling with this issue, but have observed something interesting. The command executes correctly on the pool master (xen3v3), and fails on a slave (xen2) with the 'database not in memory' error. Following is the xensource.log file on the pool master in both cases. -- successful attempt from master. Log on master -- Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi||cli] xe pool-dump-database password=null file-name=pool-dump-database.20121116173600 username=root Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|session.login_with_password D:2d839a80985d|xapi] Session.create trackid=8e34ba23e24c9883b5c413ddfcb356bc pool=false uname=root is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49 Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|task.create D:ebb96e910762|taskhelper] task dump database R:be1da62787ce (uuid:35f0640e-c59a-5f2b-f5e9-a6e869f2) created (trackid=8e34ba23e24c9883b5c413ddfcb356bc) by task D:ebb96e910762 Nov 16 17:36:02 xen3v3 xapi: [ info|xen3v3|10238 INET 0.0.0.0:80||taskhelper] task dump database R:be1da62787ce forwarded (trackid=8e34ba23e24c9883b5c413ddfcb356bc) Nov 16 17:36:03 xen3v3 xapi: [ info|xen3v3|10236 UNIX /var/xapi/xapi|session.logout D:7b78ff9cc719|xapi] Session.destroy trackid=8e34ba23e24c9883b5c413ddfcb356bc failed attempt from slave. Log on master Nov 16 17:41:08 xen3v3 xapi: [debug|xen3v3|11148 UNIX /var/xapi/xapi||dummytaskhelper] task dispatch:event.from D:f31d73627b1e created by task D:1f9945cc5399 Nov 16 17:41:10 xen3v3 xapi: [debug|xen3v3|11149 INET 0.0.0.0:80||dummytaskhelper] task dispatch:session.get_uuid D:c0b914428578 created by task D:ee2a926fc137 Nov 16 17:41:10 xen3v3 xapi: [debug|xen3v3|11149 INET 0.0.0.0:80|dispatch:session.get_uuid D:c0b914428578|api_readonly] session.get_uuid Nov 16 17:41:10 xen3v3 xapi: [ info|xen3v3|11150 INET 0.0.0.0:80||cli] xe pool-dump-database password=null file-name=pool-dump-database.20121116174110 username=root Nov 16 17:41:11 xen3v3 xapi: [ info|xen3v3|11150 INET 0.0.0.0:80|task.create D:a7fff784ed18|taskhelper] task dump database R:b2185135d308 (uuid:6d6d8e2c-df90-8cb3-1603 -698c87ec4a6c) created (trackid=9c40424ccae8e6ab343a904ecd1a7f4c) by task D:a7fff784ed18 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11150 INET 0.0.0.0:80||cli] /pool/xmldbdump?session_id=OpaqueRef:72f48933-ffd3-f6de-bc27-6d71f38e9777task_id=OpaqueRef:b218 5135-d308-c183-1b21-5eb561db5511 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11151 INET 0.0.0.0:80||dummytaskhelper] task dispatch:session.slave_login D:b2b15de6d447 created by task D:631b2c68a809 Nov 16 17:41:11 xen3v3 xapi: [ info|xen3v3|11151 INET 0.0.0.0:80|session.slave_login D:c38111cf7aa1|xapi] Session.create trackid=398737a9788c502c00dda1747cffb792 pool= true uname= is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11151 INET 0.0.0.0:80|session.slave_login D:c38111cf7aa1|mscgen] xapi=xapi [label=methodCallmethodNamesession.get_uuid/methodNameparamsparamvalueOpaqueRef:d021831a-5298-5975-9960-0c10862a11ad/value/paramparamvalueOpaqueRef:d021831a-5298-5975-9960-0c10862a11ad/value/param/params/methodCall]; Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|4 UNIX /var/xapi/xapi||xapi] Set threads number soft limit to 67.351919 with 0.334173 confidence and 0.984833 tolerance, the next tweak will be 60.00 seconds away at the earliest. Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11152 UNIX /var/xapi/xapi||dummytaskhelper] task dispatch:session.get_uuid D:c4cd084c3e8c created by task D:c38111cf7aa1 Nov 16 17:41:11 xen3v3 xapi: [debug|xen3v3|11152 UNIX /var/xapi/xapi|dispatch:session.get_uuid D:c4cd084c3e8c|api_readonly]
