Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Users

Recommended Best way to Upgrade/Update Xen

 

 

Xen users RSS feed   Index | Next | Previous | View Threaded


cyberhawk001 at gmail

May 10, 2012, 2:30 PM

Post #1 of 5 (781 views)
Permalink
Recommended Best way to Upgrade/Update Xen

This might be a silly question for most, but since Xen is ever so
changing with regular changesets and updates, what is the "best
practice" way to upgrade / update or even downgrade Xen?

1.) Is it by booting into regular Linux Kernel without Xen, do a
complete uninstall of the old Xen, than install the newly compiled Xen?

2.) Is it by booting into regular Linux Kernel without Xen, than install
the newly compiled Xen, were it will / should overwrite everything with
the new version?



_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


andy at finkenstadt

May 10, 2012, 2:48 PM

Post #2 of 5 (744 views)
Permalink
Re: Recommended Best way to Upgrade/Update Xen [In reply to]

This is a good question to know. Much will depend on what you mean by
"Xen" and updating "Xen".

In my particular case, I run generic Distro-based Xen 3.0.x under CentOS
5.7, and will be upgrading to GITCO-based Xen 4.1.2. My upgrade steps are

Distribution Install:

# yum update
# yum groupinstall Xen
# vi /etc/grub.conf
# reboot

Upgrade install to 4.1.2:

# cd /etc/yum.repos.d
# wget http://www.gitco.de/repo/GITCO-XEN4.1.2_x86_64.repo
# rpm -e --nodeps libvirt.i386
# rpm -e --nodeps libvirt.x86_64
# rpm -e --nodeps libvirt-python
# yum update
# vi /etc/grub.conf
line of the active stanzas. Dell R610 with MegaRAID requires it.
# reboot

--Andy


On Thu, May 10, 2012 at 4:30 PM, <cyberhawk001 [at] gmail> wrote:

> This might be a silly question for most, but since Xen is ever so changing
> with regular changesets and updates, what is the "best practice" way to
> upgrade / update or even downgrade Xen?
>
> 1.) Is it by booting into regular Linux Kernel without Xen, do a complete
> uninstall of the old Xen, than install the newly compiled Xen?
>
> 2.) Is it by booting into regular Linux Kernel without Xen, than install
> the newly compiled Xen, were it will / should overwrite everything with the
> new version?
>
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users [at] lists
> http://lists.xen.org/xen-users
>


cyberhawk001 at gmail

May 10, 2012, 3:23 PM

Post #3 of 5 (742 views)
Permalink
Re: Recommended Best way to Upgrade/Update Xen [In reply to]

humm, OK in that case, i guess i should be a little more detailed. I did:

- Debian Wheezy 64bit
- It was original installed with kernel 3.2.0-2-amd64
- Next compiled and installed kernel 3.3.4, where only modified .config
to enabled all Xen options
- Rebooted into kernel 3.3.4 to make sure it works first. (Didn't remove
kernel 3.2.0-2-amd64 in case of issues)
- Compiled and installed Xen 4.2-unstable with the latest changeset 25269
- Rebooted into Xen 4.2-unstable using kernel 3.3.4

So you do some testing in Xen 4.2-unstable, to make sure the latest
updates to the Xen 4.2-unstable source didn't mess something up. But, if
you need to go back to a previous changest, OR even downgrade to Xen
4.1.2, would you:

A.) Reboot into kernel 3.3.4 without xen, do a complete remove of Xen
4.2-unstable (using synaptic sudo apt-get autoremove xen*** or similar),
than install the next package you want to test, and reboot into Xen***
with Kernel 3.3.4?

B.) OR boot into kernel 3.3.4 without xen, and install the newly built
Xen DEB package without first removing it, which will overwrite all
current files and directories with the new one?

For the sake making it simpler to test a bunch of changesets, nothing
else was changed or removed, not the /etc/network/interfaces, or
/etc/modules, didn't update grub.cfg until the new Xen was installed,
and only Xen was removed / reinstalled.



> This is a good question to know. Much will depend on what you mean by
> "Xen" and updating "Xen".
>
> In my particular case, I run generic Distro-based Xen 3.0.x under
> CentOS 5.7, and will be upgrading to GITCO-based Xen 4.1.2. My
> upgrade steps are
>
> Distribution Install:
>
> # yum update
> # yum groupinstall Xen
> ==> or yum groupinstall Virtualization, before CentOS 5.8 had been
> released.
> # vi /etc/grub.conf
> ==> change default= to use the Xen kernel= stanza.
> # reboot
>
> Upgrade install to 4.1.2:
>
> # cd /etc/yum.repos.d
> # wget http://www.gitco.de/repo/GITCO-XEN4.1.2_x86_64.repo
> # rpm -e --nodeps libvirt.i386
> # rpm -e --nodeps libvirt.x86_64
> # rpm -e --nodeps libvirt-python
> # yum update
> # vi /etc/grub.conf
> ==> consider whether your hardware requires pci=nomsi on the
> module=vmlinuz line of the active stanzas. Dell R610 with MegaRAID
> requires it.
> # reboot
>
> --Andy
>
>
> On Thu, May 10, 2012 at 4:30 PM, <cyberhawk001 [at] gmail
> <mailto:cyberhawk001 [at] gmail>> wrote:
>
> This might be a silly question for most, but since Xen is ever so
> changing with regular changesets and updates, what is the "best
> practice" way to upgrade / update or even downgrade Xen?
>
> 1.) Is it by booting into regular Linux Kernel without Xen, do a
> complete uninstall of the old Xen, than install the newly compiled
> Xen?
>
> 2.) Is it by booting into regular Linux Kernel without Xen, than
> install the newly compiled Xen, were it will / should overwrite
> everything with the new version?
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users [at] lists <mailto:Xen-users [at] lists>
> http://lists.xen.org/xen-users
>
>


cdelorme at gmail

May 10, 2012, 3:35 PM

Post #4 of 5 (741 views)
Permalink
Re: Recommended Best way to Upgrade/Update Xen [In reply to]

If you built from .deb, you can use "dpkg -r" to remove the current
installation.

Or if from source if you kept the src folder you can use make uninstall to
run the same removal script.

I did both a number of times successfully, uninstall/remove then recompile
new revision and install.

FYI, I usually keep the source just in case I want to revert back.

On Thu, May 10, 2012 at 6:23 PM, <cyberhawk001 [at] gmail> wrote:

> humm, OK in that case, i guess i should be a little more detailed. I did:
>
> - Debian Wheezy 64bit
> - It was original installed with kernel 3.2.0-2-amd64
> - Next compiled and installed kernel 3.3.4, where only modified .config to
> enabled all Xen options
> - Rebooted into kernel 3.3.4 to make sure it works first. (Didn't remove
> kernel 3.2.0-2-amd64 in case of issues)
> - Compiled and installed Xen 4.2-unstable with the latest changeset 25269
> - Rebooted into Xen 4.2-unstable using kernel 3.3.4
>
> So you do some testing in Xen 4.2-unstable, to make sure the latest
> updates to the Xen 4.2-unstable source didn't mess something up. But, if
> you need to go back to a previous changest, OR even downgrade to Xen 4.1.2,
> would you:
>
> A.) Reboot into kernel 3.3.4 without xen, do a complete remove of Xen
> 4.2-unstable (using synaptic sudo apt-get autoremove xen*** or similar),
> than install the next package you want to test, and reboot into Xen*** with
> Kernel 3.3.4?
>
> B.) OR boot into kernel 3.3.4 without xen, and install the newly built Xen
> DEB package without first removing it, which will overwrite all current
> files and directories with the new one?
>
> For the sake making it simpler to test a bunch of changesets, nothing else
> was changed or removed, not the /etc/network/interfaces, or /etc/modules,
> didn't update grub.cfg until the new Xen was installed, and only Xen was
> removed / reinstalled.
>
>
>
>
> This is a good question to know. Much will depend on what you mean by
> "Xen" and updating "Xen".
>
> In my particular case, I run generic Distro-based Xen 3.0.x under CentOS
> 5.7, and will be upgrading to GITCO-based Xen 4.1.2. My upgrade steps are
>
> Distribution Install:
>
> # yum update
> # yum groupinstall Xen
> ==> or yum groupinstall Virtualization, before CentOS 5.8 had been
> released.
> # vi /etc/grub.conf
> ==> change default= to use the Xen kernel= stanza.
> # reboot
>
> Upgrade install to 4.1.2:
>
> # cd /etc/yum.repos.d
> # wget http://www.gitco.de/repo/GITCO-XEN4.1.2_x86_64.repo
> # rpm -e --nodeps libvirt.i386
> # rpm -e --nodeps libvirt.x86_64
> # rpm -e --nodeps libvirt-python
> # yum update
> # vi /etc/grub.conf
> ==> consider whether your hardware requires pci=nomsi on the
> module=vmlinuz line of the active stanzas. Dell R610 with MegaRAID
> requires it.
> # reboot
>
> --Andy
>
>
> On Thu, May 10, 2012 at 4:30 PM, <cyberhawk001 [at] gmail> wrote:
>
>> This might be a silly question for most, but since Xen is ever so
>> changing with regular changesets and updates, what is the "best practice"
>> way to upgrade / update or even downgrade Xen?
>>
>> 1.) Is it by booting into regular Linux Kernel without Xen, do a complete
>> uninstall of the old Xen, than install the newly compiled Xen?
>>
>> 2.) Is it by booting into regular Linux Kernel without Xen, than install
>> the newly compiled Xen, were it will / should overwrite everything with the
>> new version?
>>
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users [at] lists
>> http://lists.xen.org/xen-users
>>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users [at] lists
> http://lists.xen.org/xen-users
>


cyberhawk001 at gmail

May 10, 2012, 3:59 PM

Post #5 of 5 (766 views)
Permalink
Re: Recommended Best way to Upgrade/Update Xen [In reply to]

> If you built from .deb, you can use "dpkg -r" to remove the current
> installation.

I also build and install from the .deb package, it just seems the
easiest. I just run:

*sudo make -j5 xen && sudo make -j5 tools && sudo make -j5 stubdom &&
sudo make -j5 deb*

which builds the .deb package as the final product

than install using *sudo dpkg -i xen-upstream-4.2-unstable.deb* so makes
sense to remove it using *dpkg -r*

> Or if from source if you kept the src folder you can use make
> uninstall to run the same removal script.

Ok that is good to know you can do that. Ya, i always keep the source
directory so i can easily update to current from the mercurial repository.

> I did both a number of times successfully, uninstall/remove then
> recompile new revision and install.
>
> FYI, I usually keep the source just in case I want to revert back.

The only thing else i do is before i do a new compile and build, i just
remove the /dist directory to avoid any conflicts it might have.

Kool, thanks Casey, that is pretty much what i was curious about...



>
> On Thu, May 10, 2012 at 6:23 PM, <cyberhawk001 [at] gmail
> <mailto:cyberhawk001 [at] gmail>> wrote:
>
> humm, OK in that case, i guess i should be a little more detailed.
> I did:
>
> - Debian Wheezy 64bit
> - It was original installed with kernel 3.2.0-2-amd64
> - Next compiled and installed kernel 3.3.4, where only modified
> .config to enabled all Xen options
> - Rebooted into kernel 3.3.4 to make sure it works first. (Didn't
> remove kernel 3.2.0-2-amd64 in case of issues)
> - Compiled and installed Xen 4.2-unstable with the latest
> changeset 25269
> - Rebooted into Xen 4.2-unstable using kernel 3.3.4
>
> So you do some testing in Xen 4.2-unstable, to make sure the
> latest updates to the Xen 4.2-unstable source didn't mess
> something up. But, if you need to go back to a previous changest,
> OR even downgrade to Xen 4.1.2, would you:
>
> A.) Reboot into kernel 3.3.4 without xen, do a complete remove of
> Xen 4.2-unstable (using synaptic sudo apt-get autoremove xen*** or
> similar), than install the next package you want to test, and
> reboot into Xen*** with Kernel 3.3.4?
>
> B.) OR boot into kernel 3.3.4 without xen, and install the newly
> built Xen DEB package without first removing it, which will
> overwrite all current files and directories with the new one?
>
> For the sake making it simpler to test a bunch of changesets,
> nothing else was changed or removed, not the
> /etc/network/interfaces, or /etc/modules, didn't update grub.cfg
> until the new Xen was installed, and only Xen was removed /
> reinstalled.
>
>
>
>
>> This is a good question to know. Much will depend on what you
>> mean by "Xen" and updating "Xen".
>>
>> In my particular case, I run generic Distro-based Xen 3.0.x under
>> CentOS 5.7, and will be upgrading to GITCO-based Xen 4.1.2. My
>> upgrade steps are
>>
>> Distribution Install:
>>
>> # yum update
>> # yum groupinstall Xen
>> ==> or yum groupinstall Virtualization, before CentOS 5.8 had
>> been released.
>> # vi /etc/grub.conf
>> ==> change default= to use the Xen kernel= stanza.
>> # reboot
>>
>> Upgrade install to 4.1.2:
>>
>> # cd /etc/yum.repos.d
>> # wget http://www.gitco.de/repo/GITCO-XEN4.1.2_x86_64.repo
>> # rpm -e --nodeps libvirt.i386
>> # rpm -e --nodeps libvirt.x86_64
>> # rpm -e --nodeps libvirt-python
>> # yum update
>> # vi /etc/grub.conf
>> ==> consider whether your hardware requires pci=nomsi on the
>> module=vmlinuz line of the active stanzas. Dell R610 with
>> MegaRAID requires it.
>> # reboot
>>
>> --Andy
>>
>>
>> On Thu, May 10, 2012 at 4:30 PM, <cyberhawk001 [at] gmail
>> <mailto:cyberhawk001 [at] gmail>> wrote:
>>
>> This might be a silly question for most, but since Xen is
>> ever so changing with regular changesets and updates, what is
>> the "best practice" way to upgrade / update or even downgrade
>> Xen?
>>
>> 1.) Is it by booting into regular Linux Kernel without Xen,
>> do a complete uninstall of the old Xen, than install the
>> newly compiled Xen?
>>
>> 2.) Is it by booting into regular Linux Kernel without Xen,
>> than install the newly compiled Xen, were it will / should
>> overwrite everything with the new version?
>>
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users [at] lists <mailto:Xen-users [at] lists>
>> http://lists.xen.org/xen-users
>>
>>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users [at] lists <mailto:Xen-users [at] lists>
> http://lists.xen.org/xen-users
>
>

Xen users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.