[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] XCP 1.6 Beta: upgrade of RAID 1 installation


  • To: xen-api@xxxxxxxxxxxxx
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
  • Date: Thu, 29 Nov 2012 14:18:19 +0400
  • Delivery-date: Thu, 29 Nov 2012 10:20:03 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>

We've meting same problem right now. Our product XCP pools are deployed over software RAID1 and upgrade is kinda require some efforts.

My idea is following:

1) migrate away guests, save /etc/xensource/*, /etc/xensource-inventory, /var/xapi to external location
2) Reinstall host on non-raid configuration (sda), put back backuped files, reboot
expected: 'vanilla' host in old pool
3) Upgrade
4) Convert it back to RAID edition.

Kinda lame, but it allow to use well tested normal upgrade procedure.

We did not perform any tests yet, so I now just a theory.


On 29.11.2012 10:35, Black Bird wrote:
Hi all

A question out of the square. ÂAnd from the outset, I know similar questions have been asked before, and that it is not a supported configuration. ÂNevertheless I suspect I'm not the only one who's interested and/or tried this out.

I have converted my XCP 1.6 Beta2 pool into a software RAID 1 setup on 2 disks, with a separate md device for the control domain's partition (md0), the backup partition (md1) and the local storage (md2). ÂIt's not that hard to do.

The problem lies when attempting an upgrade. ÂThe XCP installation process does not recognise that there is an existing installation and assumes a fresh installation, which would of course wipe everything clean.

My plan for a possible way forward is, on the master,:
(a) make a pool-dump-database and store safely
(b) extract one hard disk and store as a recovery strategy
(c) carry out a fresh installation on the remaining hard disk, selecting no local SR. ÂI expect this will overwrite the first partition and wipe out any raid configuration., not use the 2nd partition (as an upgrade is not detected, and not touch the 3rd partition.
(d) start the third md device md2 with a missing member
(d) use pool-restore-database. ÂAt this stage, I expect all metadata existing prior to the 'upgrade' is restored and that the local SR is now usable on md2
(e) carry out the conversion process from single to 2 RAID 1 disks again on the master.

I can't think of an appropriate procedure for the slave. ÂI expect host-backup/restore are not appropriate as they will simply restore the old binaries, and pool-restore-database will probably not work on the slave (I've documented elsewhere the failure of pool-dump-database). ÂSo for the slave I can only think of a fresh installation and subsequent pool-join. ÂThe only problem is the local SR on the slave - I suspect all VDIs on the local SR will need to be exported to another shared SR beforehand, unless sr-probe should help (on another host-id?). ÂFinally, convert to RAID1 as before.

My main concern is whether the pool-restore-database is likely to work between versions. ÂMy expectation is that between 1.6Beta2 and 1.6Final, the delta possibly considered minor, there should be no changes in metadata formats, but this may not apply between major versions.

I'd be grateful for any direction in the matter.


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.