Re: [ovirt-users] oVirt All-in-One upgrade path and requested improvements

[Neal Gompa]

On Tue, May 10, 2016 at 11:56 AM, Nir Soffer  wrote:
>
> I agree that hosted engine is not a replacement for all in one
> configuration. It adds lot of unneeded complexity that is not useful
> for single host use case.
>
> Can you explain why you use ovirt for your single host use case,
> and not simpler solution like virt-manager?
>
> ovirt adds lot of complexity and overhead that is not required for
> running couple of vms on a single machine with local storage.
>

My "single host" is a rather large and powerful server. Ideally, it
would be the start of an oVirt cluster, but it looks like I'd have to
rebuild it to grow it. That said, the all-in-one configuration makes
it easy to get started using and learning oVirt. And most certainly,
using virt-manager is fine for a couple of VMs, but when you're
running more than a dozen, it gets extremely annoying to manage in
virt-manager. oVirt makes that a pretty pleasurable experience. Maybe
that's not the case you guys designed it for, but I've appreciated
being able to stand up a super-powerful individual virtualization host
with oVirt and potentially have the flexibility to grow it into a
useful cluster.

On Tue, May 10, 2016 at 4:16 PM, Yedidyah Bar David  wrote:
> On Tue, May 10, 2016 at 6:20 PM, Neal Gompa  wrote:
>> Hello,
>>
>> I recently found out that oVirt "deprecated" the All-in-One
>> configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is
>> a huge problem for me, as it means that my oVirt machines don't have
>> an upgrade path.
>>
>> My experiments with the self-hosted engine have ended in failure for a
>> couple of reasons:
>> * The hosted engine deploy expects that a FQDN is already paired with
>> an IP address. This is obviously false in most home environments, and
>> even in the work environment where I use oVirt regularly. There's no
>> workaround for this (except having a third machine to run the
>> engine!), and this utterly breaks the only way to use oVirt in a
>> DHCP-centric environment where I may not control the network
>> addressing.
>
> There is a simple workaround:
>
> 1. Pick up an FQDN for the engine
> 2. Add a relevant line to /etc/hosts on the host, with a fake
> IP address
> 3. After the engine VM is up and you know its IP address, fix
> the line in /etc/hosts to map to the real address. Also add the
> same line to /etc/hosts on the engine vm (and all other hosts).
>
> I agree it's ugly, but I use this quite a lot when I have to.
>

I'll try that next time around. Thanks.

>>
>> * Other error states have caused the whole thing to break and just
>> leave the system a broken mess. With no way to clean up, I'm left
>> guessing how to undo everything, which is hellish and leads me to just
>> wipe the whole system and start over.
>
> Unlike engine-setup, which is used also for upgrades, hosted-engine
> --deploy is ran only for a clean install, so reinstalling the host
> is much easier than implementing full rollback as in engine-setup.
>
> See also:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1001181
> http://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-failed-install
>

Being able to clean up a hosted-engine --deploy would allow me to try
again if it fails. But I guess the script in the docs is sufficient...

>>
>> In addition, I was hoping that there would be improvements with the
>> single system case, rather than destruction of this capability. Some
>> of the improvements are things I think would be useful in even a
>> multi-node setup, too.
>>
>> For example, I would like to see live migration capabilities with
>> local storage across datacenters, as this capability in vMotion makes
>> deployments a lot more flexible. Sometimes, local storage is really
>> the only way to get the kind of speed needed for some workloads, and
>> being able to offer some kind of HA for VMs on local storage would be
>> excellent. In addition to being useful for all-in-one setups, it's
>> quite useful for self-hosted engine configurations, too.
>>
>> It's also rather irritating that there's no way to migrate stuff from
>> shared storage to local storage and back. On top of that, datacenters
>> that have local storage can't have shared storage or vice versa.
>>
>> On top of that, it looks like the all-in-one code is being kept around
>> anyway for the oVirt Live stuff, so why not just keep the capability
>> and improve it? oVirt should become the best virtualization solution
>> for everyone, not just people who have access to huge datacenters
>> where all the conditions are perfect.
>
> You mention several different issues, some unrelated or even irrelevant
> to all-in-one. I'd suggest opening a thread and/or RFE per each. I'll not
> personally comment because it's not my expertise.

I've opened up an RFE for local storage live migration feature some
time ago[1], when I first found out about the all-in-one feature going
away. I've just filed an RFE for 

Re: [ovirt-users] oVirt All-in-One upgrade path and requested improvements

[Yedidyah Bar David]

On Tue, May 10, 2016 at 6:20 PM, Neal Gompa  wrote:
> Hello,
>
> I recently found out that oVirt "deprecated" the All-in-One
> configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is
> a huge problem for me, as it means that my oVirt machines don't have
> an upgrade path.
>
> My experiments with the self-hosted engine have ended in failure for a
> couple of reasons:
> * The hosted engine deploy expects that a FQDN is already paired with
> an IP address. This is obviously false in most home environments, and
> even in the work environment where I use oVirt regularly. There's no
> workaround for this (except having a third machine to run the
> engine!), and this utterly breaks the only way to use oVirt in a
> DHCP-centric environment where I may not control the network
> addressing.

There is a simple workaround:

1. Pick up an FQDN for the engine
2. Add a relevant line to /etc/hosts on the host, with a fake
IP address
3. After the engine VM is up and you know its IP address, fix
the line in /etc/hosts to map to the real address. Also add the
same line to /etc/hosts on the engine vm (and all other hosts).

I agree it's ugly, but I use this quite a lot when I have to.

>
> * Other error states have caused the whole thing to break and just
> leave the system a broken mess. With no way to clean up, I'm left
> guessing how to undo everything, which is hellish and leads me to just
> wipe the whole system and start over.

Unlike engine-setup, which is used also for upgrades, hosted-engine
--deploy is ran only for a clean install, so reinstalling the host
is much easier than implementing full rollback as in engine-setup.

See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1001181
http://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-failed-install

>
> In addition, I was hoping that there would be improvements with the
> single system case, rather than destruction of this capability. Some
> of the improvements are things I think would be useful in even a
> multi-node setup, too.
>
> For example, I would like to see live migration capabilities with
> local storage across datacenters, as this capability in vMotion makes
> deployments a lot more flexible. Sometimes, local storage is really
> the only way to get the kind of speed needed for some workloads, and
> being able to offer some kind of HA for VMs on local storage would be
> excellent. In addition to being useful for all-in-one setups, it's
> quite useful for self-hosted engine configurations, too.
>
> It's also rather irritating that there's no way to migrate stuff from
> shared storage to local storage and back. On top of that, datacenters
> that have local storage can't have shared storage or vice versa.
>
> On top of that, it looks like the all-in-one code is being kept around
> anyway for the oVirt Live stuff, so why not just keep the capability
> and improve it? oVirt should become the best virtualization solution
> for everyone, not just people who have access to huge datacenters
> where all the conditions are perfect.

You mention several different issues, some unrelated or even irrelevant
to all-in-one. I'd suggest opening a thread and/or RFE per each. I'll not
personally comment because it's not my expertise.

For all-in-one, I tend to agree with Nir: What's wrong with virt-manager?

>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



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

Re: [ovirt-users] oVirt All-in-One upgrade path and requested improvements

[Nir Soffer]

On Tue, May 10, 2016 at 6:20 PM, Neal Gompa  wrote:
> Hello,
>
> I recently found out that oVirt "deprecated" the All-in-One
> configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is
> a huge problem for me, as it means that my oVirt machines don't have
> an upgrade path.
>
> My experiments with the self-hosted engine have ended in failure for a
> couple of reasons:
> * The hosted engine deploy expects that a FQDN is already paired with
> an IP address. This is obviously false in most home environments, and
> even in the work environment where I use oVirt regularly. There's no
> workaround for this (except having a third machine to run the
> engine!), and this utterly breaks the only way to use oVirt in a
> DHCP-centric environment where I may not control the network
> addressing.
>
> * Other error states have caused the whole thing to break and just
> leave the system a broken mess. With no way to clean up, I'm left
> guessing how to undo everything, which is hellish and leads me to just
> wipe the whole system and start over.
>
> In addition, I was hoping that there would be improvements with the
> single system case, rather than destruction of this capability. Some
> of the improvements are things I think would be useful in even a
> multi-node setup, too.
>
> For example, I would like to see live migration capabilities with
> local storage across datacenters, as this capability in vMotion makes
> deployments a lot more flexible. Sometimes, local storage is really
> the only way to get the kind of speed needed for some workloads, and
> being able to offer some kind of HA for VMs on local storage would be
> excellent. In addition to being useful for all-in-one setups, it's
> quite useful for self-hosted engine configurations, too.
>
> It's also rather irritating that there's no way to migrate stuff from
> shared storage to local storage and back. On top of that, datacenters
> that have local storage can't have shared storage or vice versa.
>
> On top of that, it looks like the all-in-one code is being kept around
> anyway for the oVirt Live stuff, so why not just keep the capability
> and improve it? oVirt should become the best virtualization solution
> for everyone, not just people who have access to huge datacenters
> where all the conditions are perfect.

I agree that hosted engine is not a replacement for all in one
configuration. It adds lot of unneeded complexity that is not useful
for single host use case.

Can you explain why you use ovirt for your single host use case,
and not simpler solution like virt-manager?

ovirt adds lot of complexity and overhead that is not required for
running couple of vms on a single machine with local storage.

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

[ovirt-users] oVirt All-in-One upgrade path and requested improvements

[Neal Gompa]

Hello,

I recently found out that oVirt "deprecated" the All-in-One
configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is
a huge problem for me, as it means that my oVirt machines don't have
an upgrade path.

My experiments with the self-hosted engine have ended in failure for a
couple of reasons:
* The hosted engine deploy expects that a FQDN is already paired with
an IP address. This is obviously false in most home environments, and
even in the work environment where I use oVirt regularly. There's no
workaround for this (except having a third machine to run the
engine!), and this utterly breaks the only way to use oVirt in a
DHCP-centric environment where I may not control the network
addressing.

* Other error states have caused the whole thing to break and just
leave the system a broken mess. With no way to clean up, I'm left
guessing how to undo everything, which is hellish and leads me to just
wipe the whole system and start over.

In addition, I was hoping that there would be improvements with the
single system case, rather than destruction of this capability. Some
of the improvements are things I think would be useful in even a
multi-node setup, too.

For example, I would like to see live migration capabilities with
local storage across datacenters, as this capability in vMotion makes
deployments a lot more flexible. Sometimes, local storage is really
the only way to get the kind of speed needed for some workloads, and
being able to offer some kind of HA for VMs on local storage would be
excellent. In addition to being useful for all-in-one setups, it's
quite useful for self-hosted engine configurations, too.

It's also rather irritating that there's no way to migrate stuff from
shared storage to local storage and back. On top of that, datacenters
that have local storage can't have shared storage or vice versa.

On top of that, it looks like the all-in-one code is being kept around
anyway for the oVirt Live stuff, so why not just keep the capability
and improve it? oVirt should become the best virtualization solution
for everyone, not just people who have access to huge datacenters
where all the conditions are perfect.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users