[ovirt-users] Stuck import?

2017-12-04 Thread Chas Ecomm
I've got a VM import that has been stuck for over 2 weeks now where I've
migrated off an 3.5 to a new set of 4.1 clusters, and one VM got stuck in
the import process.  I was able to re-export it and import it successfully,
but the GUI has been showing this VM hanging there for over 3 weeks.  I
can't find an active task on the SPM using vdsClient, either.

 

Is there some way to clear the tasks out of the GUI if they don't appear on
the SPM? 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Upgrading from Hosted Engine 3.6 to 4.X

2017-11-27 Thread Chas Ecomm
In my experience, though, you can't restore from a 3.6 engine backup to a
4.1 engine.  You'd have to install 4.0, restore, then upgrade to 4.1
wouldn't you?

-Original Message-
From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of
Cam Wright
Sent: Wednesday, November 22, 2017 6:54 PM
To: Yedidyah Bar David 
Cc: users@ovirt.org
Subject: Re: [ovirt-users] Upgrading from Hosted Engine 3.6 to 4.X

Thanks for your response. Good to know that what I've suggested isn't
completely whacky!

> You didn't mention if you can stand downtime for your VMs or not.
We can't afford a lot of downtime on the VMs, probably 1-2 hours early
morning at maximum given business needs, but we'd prefer to not have any
downtime if at all possible.

...on your suggested plan, as that seems the more sane option if we can get
a bigger maintenance window than the aforementioned couple of hours.
The biggest issue I can see even in step one, however, is that all of our
hosts are hosted-engine hosts, in that all four hosts are capable of running
the engine.. so we'd need to bring both clusters (i.e.: all
hosts) down.

Having said that, it seems like a safer plan... as long as business
requirements can accommodate.

Thanks again.

-C



Cam Wright - Systems and Technical Resource Administrator CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200M 0420 827 007
E cwri...@cuttingedge.com.au | W www.cuttingedge.com.au

/SYD /BNE /TYO


On Wed, Nov 22, 2017 at 11:56 PM, Yedidyah Bar David 
wrote:
> On Wed, Nov 22, 2017 at 2:46 PM, Cam Wright 
wrote:
>>
>> Hi there,
>>
>> We're looking to upgrade our hosted engine setup from 3.6 to 4.0 (or
4.1)...
>>
>> We built the 3.6 setup a couple of years ago with Fedora 22 (we 
>> wanted the newer-at-the-time kernel 4.4) on the hosts and engine, but 
>> when we move to 4.X we'd like to move to EL7 on the engine (as that 
>> seems to be the supported version) and to the oVirt Node ISO 
>> installer on the hypervisors.
>>
>> We've got only four hosts in our oVirt datacentre, configured in two
clusters.
>>
>> Our current idea is to take a backup of the oVirt database using the 
>> backup-restore tool, and to take a 'dd' of the virtual disk too, for 
>> good measure. Then upgrade the engine to 4.X and confirm that the 3.6 
>> hosts will run, and then finally piecemeal upgrade the hosts to 4.X 
>> using the oVirt Node ISO installer.
>>
>> Looking at this page -
>> https://www.ovirt.org/documentation/self-hosted/chap-Maintenance_and_
>> Upgrading_Resources/
>> - it seems the 'hosted-engine --upgrade-appliance' path is the best 
>> way to do this... but because our hosts are running Fedora instead of 
>> EL, I think that makes this option moot to us.
>
> Basically yes. You might be able to somehow patch it to enforce this, 
> not sure it's worth it.
>
>>
>> Is what I've suggested a valid upgrade path, or is there a more sane 
>> way of going about this?
>
> Sounds reasonable.
>
> You didn't mention if you can stand downtime for your VMs or not.
> If not, or if you need to minimize it, you should design and test
carefully.
>
> If you can, something like this should work:
>
> 1. Take down all VMs on all hosts that are hosted-engine hosts 2. Move 
> all hosted-engine hosts to maintenance 3. Remove one hosted-engine 
> host from the engine 4. Take a backup 5. Reinstall the host as el7 6. 
> Deploy new hosted-engine on new storage on this host, tell it to not 
> run engine-setup 7. Inside the new engine vm, restore the backup and 
> engine-setup 8. See that you can start the VMs on the new host 9. 
> Remove the other host on that cluster, reinstall it with el7, add 10. 
> Handle the other cluster
>
> Plan well and test well. You can use VMs and nested-kvm for the testing.
> Do not restore a backup of the real engine on a test vm that has 
> access to your hosts - it will try to manage them. Do the testing in 
> an isolated network.
>
> Best regards,
>
>>
>> -C
>>
>> Cam Wright - Systems and Technical Resource Administrator CUTTINGEDGE 
>> /
>> 90 Victoria St, West End, Brisbane, QLD, 4101
>> T + 61 7 3013 6200M 0420 827 007
>> E cwri...@cuttingedge.com.au | W www.cuttingedge.com.au
>>
>> /SYD /BNE /TYO
>>
>> --
>>
>>
>> This email is confidential and solely for the use of the intended
recipient.
>>   If you have received this email in error please notify the author 
>> and delete it immediately. This email is not to be distributed 
>> without the author's written consent. Unauthorised forwarding, 
>> printing, copying or use is strictly prohibited and may be a breach 
>> of copyright. Any views expressed in this email are those of the 
>> individual sender unless specifically stated to be the views of 
>> Cutting Edge Post Pty Ltd (Cutting Edge). Although this email has 
>> been sent in the belief that it is virus-free, it is the 
>> responsibility of the recipient to ensure that it is virus free. 

[ovirt-users] HEVM root reset?

2017-10-28 Thread Chas Ecomm
TIA for any guidance you can give me here, I'm in a bit of a pickle and have
spent many hours reading many posts and blogs that don't seem to get me
where I need to be, and despite my gut feeling that someone has had to have
dealt with this somewhere else, my google-fu is failing me in finding anyone
who has dealt with this particular problem.

 

My issue:

 

I've inherited a 4.1 hosted-engine setup.  This is for a non-profit, so the
previous consultant did what she could to save capital expense by using
older gear and oVirt rather than VMware/Hyper-V and newer equipment.  For
the most part it has worked quite well as I understand it.  This particular
setup has gone from 3.5 with a standalone engine to 4.1 with a hosted
engine, in case that matters.

 

The VMs hosted on the 2 clusters associated with this engine are currently
working fine, but I am trying to get into the hosted-engine VM, and either
there was a problem with the root password during setup and the
hosted-engine-setup script didn't catch it or I've been given a bad
password.  The previous admin didn't setup any alternative users, which is a
major no-no in my book, and so I'm trying to do that - but I can't login to
the VM.  I can log into the portal and manage the hosts, storage, VMs, etc.,
just not the HEVM.  As I understand it, even if I could set aside my need
for alternate users, when it comes time to upgrade I will need access to the
HEVM, so I have to solve this at some point.

 

If this were a physical machine, I'd reboot in single user mode and work at
things from there, but it's not, and I've not found a good guide to get to
the engine console to put it into single user mode.  I've found lots (and
lots, and lots) of links on the oVirt docs site regarding hosted engine
setups that simply don't exist as pages anymore and others that don't
address this issue, as well as a couple of links on the RedHat site that
made me think I could connect via ssh to the host running the VM, and do
some sort of X forwarding, but I haven't come anywhere close to success with
that, and since I can't log into the VM, I'm not sure how that would work
anyway.  I've always struggled with X forwarding, too, so that doesn't help,
I'm sure.

 

I read a few posts from what look like the early days of the hosted-engine
OVA implying you could launch a console from the management portal and maybe
try to reboot and set single user mode there, but they all dead-ended.
Also, I may be confused on how the hosted engine works (I find this much
more confusing than either VMware or Hyper-V), but if I'm connected to the
console via the oVirt management portal and I reboot the VM to try and get
into single user mode, wouldn't I lose my connection and still not be able
to get into single user mode?

 

I can connect via hosted-engine -console, but that asks me for the root
password, which of course I don't have.  

 

Am I just doomed to have to rebuild this whole set of servers from scratch
or is there some way I could either re-run hosted-engine -deploy so I can
set the root password and not lose my current config; or alternatively is
there a way to get the VM into single user mode and accessible so I can use
normal Linux practices for a lost root password?

 

Thanks for listening and for any help you can possibly give.  I'm sure
there's some simple thing that I've overlooked, but after hours and hours of
trying to solve this one on my own, I have to admit the need for help.

 

Thank you

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Older hardware deployment

2015-09-24 Thread Chas Ecomm
It gives the “Host CPU type is not compatible with Cluster Properties” message, 
and it doesn’t matter what CPU compatibility level I set it to (I’ve tried all 
of them) it gives the same error.  I’ve seen a few others with this kind of 
issue but not a solid description of how to modify the database to include 
processor families prior to Conroe.

 

From: Donny Davis [mailto:do...@cloudspin.me] 
Sent: Thursday, September 24, 2015 7:19 PM
To: Chas Ecomm <chash...@speakfree.net>
Cc: users <users@ovirt.org>
Subject: Re: [ovirt-users] Older hardware deployment

 

What errors are you getting?

On Sep 22, 2015 5:47 PM, "Chas Ecomm" <chash...@speakfree.net 
<mailto:chash...@speakfree.net> > wrote:

I’ve searched on this issue all over the place and not found a full answer.

 

I’ve got a lab with older Dell PE860 servers with Pentium D processors.  We are 
attempting to prove out that we can move from VMware to KVM and oVirt, but with 
3.5 we can’t get these servers to enter into a cluster due to the age of the 
processors.

 

I’ve seen it referenced in a few list entries to modify ‘the database’ to put 
CPUInfo entries in for the processor capabilities of this processor, but it is 
unclear to me and I’ve been unable to find any documentation that speaks to 
what database and how to modify it safely.

 

I know we could update these servers and get better power consumption, heat 
generation, etc., but it’s not in the cards and I can’t move my newer servers 
until we prove it out with these older ones, which ran ESXi 5.5 with absolutely 
no issue.  This cluster will be a functional test and small tools cluster 
ultimately, so I don’t really care about their lower end specs, either.

 

Would installing something older than 3.5 help me here?  Or is there some doc 
somewhere I’ve just not found that describes this process of updating the DB 
with these CPU parameters.

 

TIA!!


___
Users mailing list
Users@ovirt.org <mailto:Users@ovirt.org> 
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] Older hardware deployment

2015-09-22 Thread Chas Ecomm
I've searched on this issue all over the place and not found a full answer.

 

I've got a lab with older Dell PE860 servers with Pentium D processors.  We
are attempting to prove out that we can move from VMware to KVM and oVirt,
but with 3.5 we can't get these servers to enter into a cluster due to the
age of the processors.

 

I've seen it referenced in a few list entries to modify 'the database' to
put CPUInfo entries in for the processor capabilities of this processor, but
it is unclear to me and I've been unable to find any documentation that
speaks to what database and how to modify it safely.

 

I know we could update these servers and get better power consumption, heat
generation, etc., but it's not in the cards and I can't move my newer
servers until we prove it out with these older ones, which ran ESXi 5.5 with
absolutely no issue.  This cluster will be a functional test and small tools
cluster ultimately, so I don't really care about their lower end specs,
either.

 

Would installing something older than 3.5 help me here?  Or is there some
doc somewhere I've just not found that describes this process of updating
the DB with these CPU parameters.

 

TIA!!

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users