Re: [ovirt-users] [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
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.
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.
----- Original Message -----
From: "Blaster" <Blaster@556nato.com> To: "Itamar Heim" <iheim@redhat.com> Cc: users@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
] 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 =
--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@redhat.com> wrote: 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--
participants (5)
-
Blaster -
Blaster
-
Itamar Heim -
Jason Greene -
Nir Soffer