Hm I definitely had included the attachment (as I can see from my Outlook’s sent folder that the message has an attachment).
I am wondering if the mailing list requires any special privilege to send messages with attachment. Does anyone know ? I can forward the doc to someone who has the power to resend it to the list if anyone volunteers to do so. To answer Nux!’s suggestion of doing a blog, but I am old fashioned guy that I have not tried that yet :) Yiping On 1/8/16, 10:35 AM, "Davide Pala" <[email protected]> wrote: >I think you've forget the attachment ... > > > >Inviato dal mio dispositivo Samsung > > >-------- Messaggio originale -------- >Da: Yiping Zhang <[email protected]> >Data: 08/01/2016 18:44 (GMT+01:00) >A: [email protected] >Oggetto: Re: A Story of a Failed XenServer Upgrade > > >See attached pdf document. This is the final procedure we adopted after >upgrading seven XenServer pools. > >Yiping > > > > > >On 1/8/16, 2:20 AM, "Alessandro Caviglione" <[email protected]> wrote: > >>Hi Yiping, >>yes, thank you very much!! >>Please share the doc so I can try again the upgrade process and see if it >>was only a "unfortunate coincidence of events" or a wrong upgrade process. >> >>Thanks! >> >>On Fri, Jan 8, 2016 at 10:20 AM, Nux! <[email protected]> wrote: >> >>> Yiping, >>> >>> Why not make a blog post about it so everyone can benefit? :) >>> >>> Lucian >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro >>> >>> ----- Original Message ----- >>> > From: "Yiping Zhang" <[email protected]> >>> > To: [email protected], [email protected] >>> > Sent: Friday, 8 January, 2016 01:31:21 >>> > Subject: Re: A Story of a Failed XenServer Upgrade >>> >>> > Hi, Alessandro >>> > >>> > Late to the thread. Is this still an issue for you ? >>> > >>> > I went thru this process before and I have a step by step document that >>> I can >>> > share if you still need it. >>> > >>> > Yiping >>> > >>> > >>> > >>> > >>> > On 1/2/16, 4:43 PM, "Ahmad Emneina" <[email protected]> wrote: >>> > >>> >>Hi Alessandro, >>> >>Without seeing the logs, or DB, it will be hard to diagnose the issue. >>> I've >>> >>seen something similar in the past, where the XenServer host version isnt >>> >>getting updated in the DB, as part of the XS upgrade process. That caused >>> >>CloudStack to use the wrong hypervisor resource to try connecting back to >>> >>the XenServers... ending up in failure. If you could share sanitized >>> >>versions of your log and db, someone here might be able to give you the >>> >>necessary steps to get your cluster back under CloudStack control. >>> >> >>> >>On Sat, Jan 2, 2016 at 1:27 PM, Alessandro Caviglione < >>> >>[email protected]> wrote: >>> >> >>> >>> No guys,as the article wrote, my first action was to put in Maintenance >>> >>> Mode the Pool Master INSIDE CS; "It is vital that you upgrade the >>> XenServer >>> >>> Pool Master first before any of the Slaves. To do so you need to >>> empty the >>> >>> Pool Master of all CloudStack VMs, and you do this by putting the Host >>> into >>> >>> Maintenance Mode within CloudStack to trigger a live migration of all >>> VMs >>> >>> to alternate Hosts" >>> >>> >>> >>> This is exactly what I've done and after the XS upgrade, no hosts was >>> able >>> >>> to communicate with CS and also with the upgraded host. >>> >>> >>> >>> Putting an host in Maint Mode within CS will trigger MM also on >>> XenServer >>> >>> host or just will move the VMs to other hosts? >>> >>> >>> >>> And again.... what's the best practices to upgrade a XS cluster? >>> >>> >>> >>> On Sat, Jan 2, 2016 at 7:11 PM, Remi Bergsma < >>> [email protected]> >>> >>> wrote: >>> >>> >>> >>> > CloudStack should always do the migration of VM's not the Hypervisor. >>> >>> > >>> >>> > That's not true. You can safely migrate outside of CloudStack as the >>> >>> power >>> >>> > report will tell CloudStack where the vms live and the db gets >>> updated >>> >>> > accordingly. I do this a lot while patching and that works fine on >>> 6.2 >>> >>> and >>> >>> > 6.5. I use both CloudStack 4.4.4 and 4.7.0. >>> >>> > >>> >>> > Regards, Remi >>> >>> > >>> >>> > >>> >>> > Sent from my iPhone >>> >>> > >>> >>> > On 02 Jan 2016, at 16:26, Jeremy Peterson <[email protected] >>> <mailto: >>> >>> > [email protected]>> wrote: >>> >>> > >>> >>> > I don't use XenServer maintenance mode until after CloudStack has >>> put the >>> >>> > Host in maintenance mode. >>> >>> > >>> >>> > When you initiate maintenance mode from the host rather than >>> CloudStack >>> >>> > the db does not know where the VM's are and your UUID's get jacked. >>> >>> > >>> >>> > CS is your brains not the hypervisor. >>> >>> > >>> >>> > Maintenance in CS. All VM's will migrate. Maintenance in XenCenter. >>> >>> > Upgrade. Reboot. Join Pool. Remove Maintenance starting at >>> hypervisor >>> >>> if >>> >>> > needed and then CS and move on to the next Host. >>> >>> > >>> >>> > CloudStack should always do the migration of VM's not the Hypervisor. >>> >>> > >>> >>> > Jeremy >>> >>> > >>> >>> > >>> >>> > -----Original Message----- >>> >>> > From: Davide Pala [mailto:[email protected]] >>> >>> > Sent: Friday, January 1, 2016 5:18 PM >>> >>> > To: [email protected]<mailto:[email protected]> >>> >>> > Subject: R: A Story of a Failed XenServer Upgrade >>> >>> > >>> >>> > Hi alessandro. If u put in maintenance mode the master you force the >>> >>> > election of a new pool master. Now when you have see the upgraded >>> host as >>> >>> > disconnected you are connected to the new pool master and the host >>> (as a >>> >>> > pool member) cannot comunicate with a pool master of an earliest >>> version. >>> >>> > The solution? Launche the upgrade on the pool master without enter in >>> >>> > maintenance mode. And remember a consistent backup!!! >>> >>> > >>> >>> > >>> >>> > >>> >>> > Inviato dal mio dispositivo Samsung >>> >>> > >>> >>> > >>> >>> > -------- Messaggio originale -------- >>> >>> > Da: Alessandro Caviglione <[email protected]<mailto: >>> >>> > [email protected]>> >>> >>> > Data: 01/01/2016 23:23 (GMT+01:00) >>> >>> > A: [email protected]<mailto:[email protected]> >>> >>> > Oggetto: A Story of a Failed XenServer Upgrade >>> >>> > >>> >>> > Hi guys, >>> >>> > I want to share my XenServer Upgrade adventure to understand if I did >>> >>> > domething wrong. >>> >>> > I upgraded CS from 4.4.4 to 4.5.2 without any issues, after all the >>> VRs >>> >>> > has been upgraded I start the upgrade process of my XenServer hosts >>> from >>> >>> > 6.2 to 6.5. >>> >>> > I do not already have PoolHA enabled so I followed this article: >>> >>> > >>> >>> > >>> >>> >>> http://www.shapeblue.com/how-to-upgrade-an-apache-cloudstack-citrix-xenserver-cluster/ >>> >>> > >>> >>> > The cluster consists of n° 3 XenServer hosts. >>> >>> > >>> >>> > First of all I added manage.xenserver.pool.master=false >>> >>> > to environment.properties file and restarted cloudstack-management >>> >>> service. >>> >>> > >>> >>> > After that I put in Maintenance Mode Pool Master host and, after all >>> VMs >>> >>> > has been migrated, I Unmanaged the cluster. >>> >>> > At this point all host appears as "Disconnected" from CS interface >>> and >>> >>> > this should be right. >>> >>> > Now I put XenServer 6.5 CD in the host in Maintenance Mode and start >>> a >>> >>> > in-place upgrade. >>> >>> > After XS6.5 has been installed, I istalled the 6.5SP1 and reboot >>> again. >>> >>> > At this point I expected that, after click on Manage Cluster on CS, >>> all >>> >>> > the hosts come back to "UP" and I could go ahead upgrading the other >>> >>> > hosts.... >>> >>> > >>> >>> > But, instead of that, all the hosts still appears as "Disconnected", >>> I >>> >>> > tried a couple of cloudstack-management service restart without >>> success. >>> >>> > >>> >>> > So I opened XenCenter and connect to Pool Master I upgraded to 6.5 >>> and it >>> >>> > appear in Maintenance Mode, so I tried to Exit from Maint Mode but I >>> got >>> >>> > the error: The server is still booting >>> >>> > >>> >>> > After some investigation, I run the command "xe task-list" and this >>> is >>> >>> the >>> >>> > result: >>> >>> > >>> >>> > uuid ( RO) : 72f48a56-1d24-1ca3-aade-091f1830e2f1 >>> >>> > name-label ( RO): VM.set_memory_dynamic_range name-description ( RO): >>> >>> > status ( RO): pending >>> >>> > progress ( RO): 0.000 >>> >>> > >>> >>> > I tried a couple of reboot but nothing changes.... so I decided to >>> shut >>> >>> > down the server, force raise a slave host to master with emergency >>> mode, >>> >>> > remove old server from CS and reboot CS. >>> >>> > >>> >>> > After that, I see my cluster up and running again, so I installed XS >>> >>> > 6.2SP1 on the "upgraded" host and added again to the cluster.... >>> >>> > >>> >>> > So after an entire day of work, I'm in the same situation! :D >>> >>> > >>> >>> > Anyone can tell me if I made something wrong?? >>> >>> > >>> >>> > Thank you very much! >>> >>> > >>>
