8:07 a.m.
New subject: [RFI] oVirt 3.6 Planning
On 12.09.2014 14:22, Itamar Heim wrote:
With oVirt 3.5 nearing GA, time to ask for "what do you want to see in
oVirt 3.6”?
+ Windows HV Support: https://bugzilla.redhat.com/show_bug.cgi?id=1125297
Without these flags, my testing shows a completely idle 4 vcpu win slave
uses ~15% of a host core, which limits overcommit ability. With them it
goes down to 3.6% in my testing. hv_relaxed on its own shows no
improvement over idle time.
Unfortunately there is a KVM kernel bug that leads to win hangs with
these flags, and so until RHEL gets 3.16, which looks like 7.1, only Fedora works:
https://bugzilla.redhat.com/show_bug.cgi?id=1091818
+ Ability to add local storage without putting the host in maintenance mode
+ Some out-of-the-box option for self-hosted engine without shared storage
(e.g. gluser, ceph, drdb, application directed replication, etc)
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:56 a.m.
New subject: [RFI] oVirt 3.6 Planning
On 12/12/2014 10:08 AM, Itamar Heim wrote:
If your existing raw images are from an ovirt storage domain you can
keep it as is and import the entire storage domain or specific vms
from it.
That's a new 3.5 feature. Mind you yii must first upgrade the storage
domain to 3.5 before reinstalling
Thanks for the tip. This didn't work for me this time. My AIO setup
started out with 3.2, upgraded all the way up to 3.5, I was missing the
OVF files, so I couldn't import the storage domain. So I bit the bullet
one more time and did it the hard way (created new VMs, disks, then
copied over the old image). This time I created a storage domain for
each VM so I can import them into a new setup individually.
Btw, what does the (master) designation by one of the storage domains
mean? When I deleted one that was a master, it just moved to another
domain.
9:57 a.m.
New subject: [RFI] oVirt 3.6 Planning
On 12/21/2014 07:56 AM, Blaster wrote:
On 12/12/2014 10:08 AM, Itamar Heim wrote:
>
> If your existing raw images are from an ovirt storage domain you can
> keep it as is and import the entire storage domain or specific vms
> from it.
> That's a new 3.5 feature. Mind you yii must first upgrade the storage
> domain to 3.5 before reinstalling
>
Thanks for the tip. This didn't work for me this time. My AIO setup
started out with 3.2, upgraded all the way up to 3.5, I was missing the
OVF files, so I couldn't import the storage domain. So I bit the bullet
one more time and did it the hard way (created new VMs, disks, then
copied over the old image). This time I created a storage domain for
each VM so I can import them into a new setup individually.
Btw, what does the (master) designation by one of the storage domains
mean? When I deleted one that was a master, it just moved to another
domain.
the pool "needs a master domain". if one doesn't exist, it is re-created.
this should hopefully go away in 3.6.
2:12 p.m.
New subject: [RFI] oVirt 3.6 Planning
----- Original Message -----
From: "Blaster" <Blaster(a)556nato.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: users(a)ovirt.org
Sent: Sunday, December 21, 2014 7:56:12 AM
Subject: Re: [ovirt-users] [RFI] oVirt 3.6 Planning
On 12/12/2014 10:08 AM, Itamar Heim wrote:
>
> If your existing raw images are from an ovirt storage domain you can
> keep it as is and import the entire storage domain or specific vms
> from it.
> That's a new 3.5 feature. Mind you yii must first upgrade the storage
> domain to 3.5 before reinstalling
>
Thanks for the tip. This didn't work for me this time. My AIO setup
started out with 3.2, upgraded all the way up to 3.5, I was missing the
OVF files, so I couldn't import the storage domain. So I bit the bullet
one more time and did it the hard way (created new VMs, disks, then
copied over the old image). This time I created a storage domain for
each VM so I can import them into a new setup individually.
Creating storage domain per vm is not a good idea.
The system is expecting all storage domain to be accessible by all hosts. So
if you have multiple storage domains and one become inaccessible, a host
may become non-operational, which will cause migration storm from this host
to other hosts. Basically, the more storage domains you have, your system
is more fragile.
Create new storage domains only when you must (e.g. separating testing and
production environments). For importing and exporting vms, you can use the
export domain.
Nir
7:09 a.m.
New subject: [RFI] oVirt 3.6 Planning
--Apple-Mail=_EE6EDC13-35C3-4D97-88CF-E3DA7149331D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
This is using an AIO configuration in a lab, no chance of a migration =
storm. I=92m just looking for an easy way to move a VM around if I need =
to. 1GB ethernet is getting mighty slow these days, and any other =
shared storage is horribly expensive for a consultant=92s home lab. 10GB =
NIC cards are becoming affordable, but the switches, not so much.
On Dec 21, 2014, at 5:12 AM, Nir Soffer <nsoffer(a)redhat.com> wrote:
]
Creating storage domain per vm is not a good idea.
=20
The system is expecting all storage domain to be accessible by all =
hosts. So
if you have multiple storage domains and one become inaccessible, a =
host
may become non-operational, which will cause migration storm from
this =
host
to other hosts. Basically, the more storage domains you have, your =
system
is more fragile.
=20
Create new storage domains only when you must (e.g. separating testing =
and
production environments). For importing and exporting vms, you can
use =
the
export domain.
=20
Nir
--Apple-Mail=_EE6EDC13-35C3-4D97-88CF-E3DA7149331D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word;
=
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><div>This is using an
AIO =
configuration in a lab, no chance of a migration storm. I=92m just =
looking for an easy way to move a VM around if I need to. 1GB =
ethernet is getting mighty slow these days, and any other shared storage =
is horribly expensive for a consultant=92s home lab. 10GB NIC cards are =
becoming affordable, but the switches, not so =
much.</div><div><br></div><div><br></div><br><div><div>On
Dec 21, 2014, =
at 5:12 AM, Nir Soffer <<a =
href=3D"mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote
=
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">]<br>Creating storage domain per =
vm is not a good idea.<br><br>The system is expecting all storage domain =
to be accessible by all hosts. So<br>if you have multiple storage =
domains and one become inaccessible, a host<br>may become =
non-operational, which will cause migration storm from this host<br>to =
other hosts. Basically, the more storage domains you have, your =
system<br>is more fragile.<br><br>Create new storage domains only when
=
you must (e.g. separating testing and<br>production environments). For =
importing and exporting vms, you can use the<br>export =
domain.<br><br>Nir</div></blockquote></div><br></body></html>=
--Apple-Mail=_EE6EDC13-35C3-4D97-88CF-E3DA7149331D--
3622
days inactive
3633
days old
5 comments
5 participants
participants (5)
-
Blaster -
Blaster
-
Itamar Heim -
Jason Greene -
Nir Soffer