4:55 p.m.
So, after many frustrating weekends of trying to upgrade ovirt from 3.1, I
have come to the conclustion that it would just be best to export all of
our VM's and Import them once I have redone the entire installation with
FC19 and ovirt 3.3. Is there a way to export the entire domain easily? Or
to bring the entire domain into a new install of the engine?
Exporting a single VM takes a very long while. It would take a couple of
days to export all of our VM's (33 total vm's using 1.017 TB of data) and
then reimport them using the normal means of exporting the machines off
then on to the export domain, load the new engine server then import them
all back in.
Any tips or tricks would be welcome.
Christian
FYI, I ran into just about every single bug that people had when upgrading
from 3.1 to 3.2 and a few more. I can't spend any more time
troubleshooting the upgrade process. If we can't do the export->import
easily or migrate the current storage domain we will probably have to get
rid of ovirt and move to another solution.
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
4:24 p.m.
On 09/30/2013 04:55 PM, Christian Kolquist wrote:
So, after many frustrating weekends of trying to upgrade ovirt from
3.1,
I have come to the conclustion that it would just be best to export all
of our VM's and Import them once I have redone the entire installation
with FC19 and ovirt 3.3. Is there a way to export the entire domain
easily? Or to bring the entire domain into a new install of the engine?
Exporting a single VM takes a very long while. It would take a couple
of days to export all of our VM's (33 total vm's using 1.017 TB of data)
and then reimport them using the normal means of exporting the machines
off then on to the export domain, load the new engine server then import
them all back in.
Any tips or tricks would be welcome.
do you have a single data domain in the DC?
is it nfs or something else?
Christian
FYI, I ran into just about every single bug that people had when
upgrading from 3.1 to 3.2 and a few more. I can't spend any more time
troubleshooting the upgrade process. If we can't do the export->import
easily or migrate the current storage domain we will probably have to
get rid of ovirt and move to another solution.
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:39 p.m.
We have a NFS storage cluster (Isilon) for the domain.
The main question: is there a way to bring in an existing storage domain
to a new engine without exporting it then importing it? This would be
good for not just upgrades but also disaster recovery as well.
On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim(a)redhat.com> wrote:
On 09/30/2013 04:55 PM, Christian Kolquist wrote:
> So, after many frustrating weekends of trying to upgrade ovirt from 3.1,
> I have come to the conclustion that it would just be best to export all
> of our VM's and Import them once I have redone the entire installation
> with FC19 and ovirt 3.3. Is there a way to export the entire domain
> easily? Or to bring the entire domain into a new install of the engine?
>
> Exporting a single VM takes a very long while. It would take a couple
> of days to export all of our VM's (33 total vm's using 1.017 TB of data)
> and then reimport them using the normal means of exporting the machines
> off then on to the export domain, load the new engine server then import
> them all back in.
>
>
> Any tips or tricks would be welcome.
>
do you have a single data domain in the DC?
is it nfs or something else?
>
> Christian
>
>
> FYI, I ran into just about every single bug that people had when
> upgrading from 3.1 to 3.2 and a few more. I can't spend any more time
> troubleshooting the upgrade process. If we can't do the export->import
> easily or migrate the current storage domain we will probably have to
> get rid of ovirt and move to another solution.
>
>
>
> ------------------------------**------------------------------**---
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ______________________________**_________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
>
>
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
6:48 p.m.
On 10/01/2013 06:39 PM, Christian Kolquist wrote:
We have a NFS storage cluster (Isilon) for the domain.
The main question: is there a way to bring in an existing storage domain
to a new engine without exporting it then importing it? This would be
good for not just upgrades but also disaster recovery as well.
yes, importing an existing data domain is a high priority for us for
next version as the issue was raised several times by community users.
for 3.3, there a few options (the first one is the cleanest)
1. "save the export part"
- stop using the domain in 3.1
- change its meta data to that of an export domain
- import it as an existing export domain to 3.3
- import the VMs
2. "re-create the VMs / import disks"
- stop using the domain in 3.1
- create a new (empty) domain in 3.3
- move all disks to the new domain (assuming you create the new nfs
export in a way allowing you to move, not copy, from the old export)
- use the register disk api to add all disks
- create VMs and associate the disks to them
yes, this one requires to document first which disk is for which VM.
i think someone scripted something around this option.
if your disks have snapshots, this may become too complex.
3. re-create the VMs and override their disks.
this was suggested several times in the past, but if you have snapshots,
not relevant.
On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim(a)redhat.com
<mailto:iheim@redhat.com>> wrote:
On 09/30/2013 04:55 PM, Christian Kolquist wrote:
So, after many frustrating weekends of trying to upgrade ovirt
from 3.1,
I have come to the conclustion that it would just be best to
export all
of our VM's and Import them once I have redone the entire
installation
with FC19 and ovirt 3.3. Is there a way to export the entire domain
easily? Or to bring the entire domain into a new install of the
engine?
Exporting a single VM takes a very long while. It would take a
couple
of days to export all of our VM's (33 total vm's using 1.017 TB
of data)
and then reimport them using the normal means of exporting the
machines
off then on to the export domain, load the new engine server
then import
them all back in.
Any tips or tricks would be welcome.
do you have a single data domain in the DC?
is it nfs or something else?
Christian
FYI, I ran into just about every single bug that people had when
upgrading from 3.1 to 3.2 and a few more. I can't spend any
more time
troubleshooting the upgrade process. If we can't do the
export->import
easily or migrate the current storage domain we will probably
have to
get rid of ovirt and move to another solution.
------------------------------__------------------------------__---
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
_________________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:40 a.m.
I am planning on testing the modify existing to become an export domain.
That will only require me to copy within the isilon cluster a copy of the
data which only will take about 1 hour. The plan is to do the following:
1. Load Fedora 19 on new engine server and install the engine, add new
storage domain shares and get fully up and running without adding any nodes
2. shutdown all VM's and then remove the nodes
3. shutdown engine on current server
4. copy the existing storage domain to another location on the NAS and
share it out over NFS.
5. Add nodes to new engine
6. Modify the copy of the storage domain to be an export domain (
http://humblec.com/convert-master-data-domain-to-export-domain-in-a-crash...
)
7. Add it in as an existing export domain on the new engine server and
start import of VM's (will take probably 4-6 hours or maybe longer, total
storage is ~1TB of data)
Are there any further suggestions to this? If this plan fails then I will
be able to revert back to the original engine server and domain.
Christian
On Tue, Oct 1, 2013 at 10:48 AM, Itamar Heim <iheim(a)redhat.com> wrote:
On 10/01/2013 06:39 PM, Christian Kolquist wrote:
> We have a NFS storage cluster (Isilon) for the domain.
>
> The main question: is there a way to bring in an existing storage domain
> to a new engine without exporting it then importing it? This would be
> good for not just upgrades but also disaster recovery as well.
>
yes, importing an existing data domain is a high priority for us for next
version as the issue was raised several times by community users.
for 3.3, there a few options (the first one is the cleanest)
1. "save the export part"
- stop using the domain in 3.1
- change its meta data to that of an export domain
- import it as an existing export domain to 3.3
- import the VMs
2. "re-create the VMs / import disks"
- stop using the domain in 3.1
- create a new (empty) domain in 3.3
- move all disks to the new domain (assuming you create the new nfs
export in a way allowing you to move, not copy, from the old export)
- use the register disk api to add all disks
- create VMs and associate the disks to them
yes, this one requires to document first which disk is for which VM.
i think someone scripted something around this option.
if your disks have snapshots, this may become too complex.
3. re-create the VMs and override their disks.
this was suggested several times in the past, but if you have snapshots,
not relevant.
>
> On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim(a)redhat.com
> <mailto:iheim@redhat.com>> wrote:
>
> On 09/30/2013 04:55 PM, Christian Kolquist wrote:
>
> So, after many frustrating weekends of trying to upgrade ovirt
> from 3.1,
> I have come to the conclustion that it would just be best to
> export all
> of our VM's and Import them once I have redone the entire
> installation
> with FC19 and ovirt 3.3. Is there a way to export the entire
> domain
> easily? Or to bring the entire domain into a new install of the
> engine?
>
> Exporting a single VM takes a very long while. It would take a
> couple
> of days to export all of our VM's (33 total vm's using 1.017 TB
> of data)
> and then reimport them using the normal means of exporting the
> machines
> off then on to the export domain, load the new engine server
> then import
> them all back in.
>
>
> Any tips or tricks would be welcome.
>
>
> do you have a single data domain in the DC?
> is it nfs or something else?
>
>
>
> Christian
>
>
> FYI, I ran into just about every single bug that people had when
> upgrading from 3.1 to 3.2 and a few more. I can't spend any
> more time
> troubleshooting the upgrade process. If we can't do the
> export->import
> easily or migrate the current storage domain we will probably
> have to
> get rid of ovirt and move to another solution.
>
>
>
> ------------------------------**__----------------------------**
> --__---
>
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ______________________________**___________________
> Users mailing list
> Users(a)ovirt.org <mailto:Users@ovirt.org>
>
http://lists.ovirt.org/__**mailman/listinfo/users<http://lists.ovirt.o...
>
<http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
> >
>
>
>
>
>
> ------------------------------**------------------------------**---
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ______________________________**_________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
>
>
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
9:36 a.m.
On 10/02/2013 12:40 AM, Christian Kolquist wrote:
I am planning on testing the modify existing to become an export
domain.
That will only require me to copy within the isilon cluster a copy of
the data which only will take about 1 hour. The plan is to do the
following:
1. Load Fedora 19 on new engine server and install the engine, add new
storage domain shares and get fully up and running without adding any nodes
just wondering - any reason you prefer fedora to .el6 (centos/rhel)?
2. shutdown all VM's and then remove the nodes
3. shutdown engine on current server
4. copy the existing storage domain to another location on the NAS and
share it out over NFS.
5. Add nodes to new engine
6. Modify the copy of the storage domain to be an export domain
(http://humblec.com/convert-master-data-domain-to-export-domain-in-a-crash...)
7. Add it in as an existing export domain on the new engine server and
start import of VM's (will take probably 4-6 hours or maybe longer,
total storage is ~1TB of data)
Are there any further suggestions to this? If this plan fails then I
will be able to revert back to the original engine server and domain.
sounds good to me
Christian
On Tue, Oct 1, 2013 at 10:48 AM, Itamar Heim <iheim(a)redhat.com
<mailto:iheim@redhat.com>> wrote:
On 10/01/2013 06:39 PM, Christian Kolquist wrote:
We have a NFS storage cluster (Isilon) for the domain.
The main question: is there a way to bring in an existing
storage domain
to a new engine without exporting it then importing it? This
would be
good for not just upgrades but also disaster recovery as well.
yes, importing an existing data domain is a high priority for us for
next version as the issue was raised several times by community users.
for 3.3, there a few options (the first one is the cleanest)
1. "save the export part"
- stop using the domain in 3.1
- change its meta data to that of an export domain
- import it as an existing export domain to 3.3
- import the VMs
2. "re-create the VMs / import disks"
- stop using the domain in 3.1
- create a new (empty) domain in 3.3
- move all disks to the new domain (assuming you create the new nfs
export in a way allowing you to move, not copy, from the old export)
- use the register disk api to add all disks
- create VMs and associate the disks to them
yes, this one requires to document first which disk is for which VM.
i think someone scripted something around this option.
if your disks have snapshots, this may become too complex.
3. re-create the VMs and override their disks.
this was suggested several times in the past, but if you have
snapshots, not relevant.
On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim(a)redhat.com
<mailto:iheim@redhat.com>
<mailto:iheim@redhat.com <mailto:iheim@redhat.com>>> wrote:
On 09/30/2013 04:55 PM, Christian Kolquist wrote:
So, after many frustrating weekends of trying to
upgrade ovirt
from 3.1,
I have come to the conclustion that it would just be
best to
export all
of our VM's and Import them once I have redone the entire
installation
with FC19 and ovirt 3.3. Is there a way to export the
entire domain
easily? Or to bring the entire domain into a new
install of the
engine?
Exporting a single VM takes a very long while. It
would take a
couple
of days to export all of our VM's (33 total vm's using
1.017 TB
of data)
and then reimport them using the normal means of
exporting the
machines
off then on to the export domain, load the new engine
server
then import
them all back in.
Any tips or tricks would be welcome.
do you have a single data domain in the DC?
is it nfs or something else?
Christian
FYI, I ran into just about every single bug that people
had when
upgrading from 3.1 to 3.2 and a few more. I can't
spend any
more time
troubleshooting the upgrade process. If we can't do the
export->import
easily or migrate the current storage domain we will
probably
have to
get rid of ovirt and move to another solution.
------------------------------____----------------------------__--__---
This email, along with any attachments, is
confidential. If you
believe you received this message in error, please
contact the
sender immediately and delete all copies of the message.
Thank you.
___________________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org
<mailto:Users@ovirt.org>>
http://lists.ovirt.org/____mailman/listinfo/users
<http://lists.ovirt.org/__mailman/listinfo/users>
<http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>>
------------------------------__------------------------------__---
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
_________________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
4:17 p.m.
On Wed, Oct 2, 2013 at 1:36 AM, Itamar Heim <iheim(a)redhat.com> wrote:
On 10/02/2013 12:40 AM, Christian Kolquist wrote:
> I am planning on testing the modify existing to become an export domain.
> That will only require me to copy within the isilon cluster a copy of
> the data which only will take about 1 hour. The plan is to do the
> following:
>
> 1. Load Fedora 19 on new engine server and install the engine, add new
> storage domain shares and get fully up and running without adding any
> nodes
>
just wondering - any reason you prefer fedora to .el6 (centos/rhel)?
We use Fedora on most of our systems here. We use kickstart and puppet to
manage them and already have nearly everything ready to go with it.
2. shutdown all VM's and then remove the nodes
> 3. shutdown engine on current server
> 4. copy the existing storage domain to another location on the NAS and
> share it out over NFS.
> 5. Add nodes to new engine
> 6. Modify the copy of the storage domain to be an export domain
> (http://humblec.com/convert-**master-data-domain-to-export-**
>
domain-in-a-crashed-**rhevmovirt-setup/<http://humblec.com/convert-mas...
> )
> 7. Add it in as an existing export domain on the new engine server and
> start import of VM's (will take probably 4-6 hours or maybe longer,
> total storage is ~1TB of data)
>
> Are there any further suggestions to this? If this plan fails then I
> will be able to revert back to the original engine server and domain.
>
sounds good to me
> Christian
>
>
>
>
> On Tue, Oct 1, 2013 at 10:48 AM, Itamar Heim <iheim(a)redhat.com
> <mailto:iheim@redhat.com>> wrote:
>
> On 10/01/2013 06:39 PM, Christian Kolquist wrote:
>
> We have a NFS storage cluster (Isilon) for the domain.
>
> The main question: is there a way to bring in an existing
> storage domain
> to a new engine without exporting it then importing it? This
> would be
> good for not just upgrades but also disaster recovery as well.
>
>
>
> yes, importing an existing data domain is a high priority for us for
> next version as the issue was raised several times by community users.
>
> for 3.3, there a few options (the first one is the cleanest)
> 1. "save the export part"
> - stop using the domain in 3.1
> - change its meta data to that of an export domain
> - import it as an existing export domain to 3.3
> - import the VMs
>
> 2. "re-create the VMs / import disks"
> - stop using the domain in 3.1
> - create a new (empty) domain in 3.3
> - move all disks to the new domain (assuming you create the new nfs
> export in a way allowing you to move, not copy, from the old
> export)
> - use the register disk api to add all disks
> - create VMs and associate the disks to them
>
> yes, this one requires to document first which disk is for which VM.
> i think someone scripted something around this option.
>
> if your disks have snapshots, this may become too complex.
>
> 3. re-create the VMs and override their disks.
> this was suggested several times in the past, but if you have
> snapshots, not relevant.
>
>
>
> On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim(a)redhat.com
> <mailto:iheim@redhat.com>
> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>>> wrote:
>
> On 09/30/2013 04:55 PM, Christian Kolquist wrote:
>
> So, after many frustrating weekends of trying to
> upgrade ovirt
> from 3.1,
> I have come to the conclustion that it would just be
> best to
> export all
> of our VM's and Import them once I have redone the entire
> installation
> with FC19 and ovirt 3.3. Is there a way to export the
> entire domain
> easily? Or to bring the entire domain into a new
> install of the
> engine?
>
> Exporting a single VM takes a very long while. It
> would take a
> couple
> of days to export all of our VM's (33 total vm's using
> 1.017 TB
> of data)
> and then reimport them using the normal means of
> exporting the
> machines
> off then on to the export domain, load the new engine
> server
> then import
> them all back in.
>
>
> Any tips or tricks would be welcome.
>
>
> do you have a single data domain in the DC?
> is it nfs or something else?
>
>
>
> Christian
>
>
> FYI, I ran into just about every single bug that people
> had when
> upgrading from 3.1 to 3.2 and a few more. I can't
> spend any
> more time
> troubleshooting the upgrade process. If we can't do the
> export->import
> easily or migrate the current storage domain we will
> probably
> have to
> get rid of ovirt and move to another solution.
>
>
>
>
> ------------------------------**____--------------------------**
> --__--__---
>
>
> This email, along with any attachments, is
> confidential. If you
> believe you received this message in error, please
> contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ______________________________**_____________________
> Users mailing list
> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org
> <mailto:Users@ovirt.org>>
>
http://lists.ovirt.org/____**mailman/listinfo/users<http://lists.ovirt...
>
<http://lists.ovirt.org/__**mailman/listinfo/users<http://lists.ovirt.o...
> >
>
<http://lists.ovirt.org/__**mailman/listinfo/users<http://lists.ovirt.o...
>
<http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
> >>
>
>
>
>
>
>
> ------------------------------**__----------------------------**
> --__---
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ______________________________**___________________
> Users mailing list
> Users(a)ovirt.org <mailto:Users@ovirt.org>
>
http://lists.ovirt.org/__**mailman/listinfo/users<http://lists.ovirt.o...
>
<http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
> >
>
>
>
>
>
> ------------------------------**------------------------------**---
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
4068
days inactive
4070
days old
6 comments
2 participants
participants (2)
-
Christian Kolquist -
Itamar Heim