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

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




On Thu, Nov 29, 2012 at 11:20 AM, Black Bird <blackbird1758@xxxxxxxxx> wrote:
With your method, you don't even need to reinstall. ÂYou could perfom the reverse process of RAID, i.e. creating a new bootable pair of partitions, creating one filesystem on a bootable one, copying the existing control domain filesystem and booting off the new partition, before carrying out the RAID again.

Where your method hits a wall is if you (as I do) have a local SR on a local software RAID (md). ÂThe main reason I expect this will not work is that the installation kernel does not seem to contain the md utilities and modules. ÂOf course one could move all VDIs to a shared SR beforehand, but there could be legitimate reasons why one would want a local SR.

Actually, the installation process to my mind should not need to actually utilise the local volumes, but just carry out changes to the binaries and configuration files, so the absence of the md modules may not be a show stopper. ÂPerhaps I need some experimentation here.


On Thu, Nov 29, 2012 at 9:18 PM, George Shuklin <george.shuklin@xxxxxxxxx> wrote:
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



_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api.
Â
I'd also love to see at least some procedure taking such installations as a consideration, as we're also using XCP/XS on software RAID1, and every upgrade is in fact a reinstallation, very suboptimal procedure. Perhaps, given the fact XCP doesnt have to be tied to 'supported configuration' as XS does, we could have mdraid support in XCP for installation/reinstallation since so many people use it?

S.
_______________________________________________
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®.