9:13 a.m.
------=_NextPartTM-000-4326d9f2-687b-46ec-9ef4-9036536f9e0c
Content-Type: multipart/alternative;
boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD1735F8FC093EXCHANGEcollogi_"
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735F8FC093EXCHANGEcollogi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
we just build a new cluster with FC20 + virt-preview repos enabled.
Idea behind that is to enable snapshot live merge feature. This
seems to work quite well.
The only culprit is the Windows activation. For some reasons the
VM hardware of the old qemu 1.6/seabios 1.7.3 hypervisors is
different to the new qemu 2.1/seabios 1.7.5. So the OS is no longer
activated.
We already activated the VMs twice. During first install on VMware
and then afterwards after the migration to OVirt. I have no problem
to reactivate them a third time. I have more fears that I must
reactivate them with each new hypervisor generation. That can
be quite a lot of phone calls.
An interesting article from the Proxmox guys can be read here:
http://forum.proxmox.com/archive/index.php/t-19743.html
Conclusion of the discussion: After you go from qemu 1.7 to 2.1
you can force the old hardware layout using -M pc-i440fx-1.7
Looking at the qemu command line in OVirt I can see our VMs
are fired up with pc-1.0,accel=3Dkvm,usb=3Doff - regardless of an
old (FC20) or a new hypervisor (FC20+virt-preview). So I would
guess that everything should work without a new reactivation.
Any ideas?
Markus
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735F8FC093EXCHANGEcollogi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Diso-8859-=
1">
<style type=3D"text/css" id=3D"owaParaStyle"></style>
</head>
<body fpstyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">Hello,
<div><br>
</div>
<div>we just build a new cluster with FC20 + virt-preview repos enabled=
.</div>
<div>Idea behind that is to enable snapshot live merge feature. This <=
/div>
<div>seems to work quite well. </div>
<div><br>
</div>
<div>The only culprit is the Windows activation. For some reasons the</div>
<div>VM hardware of the old qemu 1.6/seabios 1.7.3 hypervisors is</div>
<div>different to the new qemu 2.1/seabios 1.7.5. So the OS is no longer</d=
iv>
<div>activated.</div>
<div><br>
</div>
<div>We already activated the VMs twice. During first install on VMware</di=
v>
<div>and then afterwards after the migration to OVirt. <span
style=3D"=
font-size: 10pt;">I have no problem</span></div>
<div><span style=3D"font-size: 10pt;">to reactivate them a third
time. I ha=
ve more fears that I must</span></div>
<div><span style=3D"font-size: 10pt;">reactivate them with each new
hypervi=
sor generation. That can</span></div>
<div><span style=3D"font-size: 10pt;">be quite a lot of phone
calls.</span>=
</div>
<div><span style=3D"font-size: 10pt;"><br>
</span></div>
<div><span style=3D"font-size: 10pt;">An interesting article from
the Proxm=
ox guys can be read here:</span></div>
<div>http://forum.proxmox.com/archive/index.php/t-19743.html<br>
</div>
<div><span style=3D"font-size: 10pt;">Conclusion of the discussion:
After y=
ou go from qemu 1.7 to 2.1 </span></div>
<div><span style=3D"font-size:
10pt;">you </span><span style=3D"font-s=
ize: 10pt;">can force the old hardware layout using </span><span
style=
=3D"font-family: verdana, arial, sans-serif; font-size: 11.1999998092651px;=
background-color: rgb(249, 249, 249);">-M pc-i440fx-1.7</span></div>
<div><br>
</div>
<div>Looking at the qemu command line in OVirt I can see our VMs</div>
<div>are fired up with pc-1.0,accel=3Dkvm,usb=3Doff - regardless of an=
</div>
<div>old (FC20) or a new hypervisor (FC20+virt-preview). So I would</di=
v>
<div>guess that everything should work without a new reactivation.</div>
<div><br>
</div>
<div>Any ideas?</div>
<div><br>
</div>
<div>Markus</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</div>
</body>
</html>
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735F8FC093EXCHANGEcollogi_--
------=_NextPartTM-000-4326d9f2-687b-46ec-9ef4-9036536f9e0c
Content-Type: text/plain;
name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="InterScan_Disclaimer.txt"
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
------=_NextPartTM-000-4326d9f2-687b-46ec-9ef4-9036536f9e0c--
5:08 p.m.
On 12/18/2014 05:13 PM, Markus Stockhausen wrote:
Hello,
we just build a new cluster with FC20 + virt-preview repos enabled.
Idea behind that is to enable snapshot live merge feature. This
seems to work quite well.
The only culprit is the Windows activation. For some reasons the
VM hardware of the old qemu 1.6/seabios 1.7.3 hypervisors is
different to the new qemu 2.1/seabios 1.7.5. So the OS is no longer
activated.
We already activated the VMs twice. During first install on VMware
and then afterwards after the migration to OVirt. I have no problem
to reactivate them a third time. I have more fears that I must
reactivate them with each new hypervisor generation. That can
be quite a lot of phone calls.
An interesting article from the Proxmox guys can be read here:
http://forum.proxmox.com/archive/index.php/t-19743.html
Conclusion of the discussion: After you go from qemu 1.7 to 2.1
you can force the old hardware layout using -M pc-i440fx-1.7
Looking at the qemu command line in OVirt I can see our VMs
are fired up with pc-1.0,accel=kvm,usb=off - regardless of an
old (FC20) or a new hypervisor (FC20+virt-preview). So I would
guess that everything should work without a new reactivation.
Any ideas?
Markus
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
for .el6/.el7 we use the stable -m machines (-m rhel6.5.0, -m
rhel-6.6.0, etc.)
fedora uses "pc" indeed. you can change it via config, but I don't know
fedora is keeping these stable for the other definitions / how to map
them to cluster levels
1:32 a.m.
On 19 Dec 2014, at 00:09, Itamar Heim <iheim(a)redhat.com>
wrote:
> On 12/18/2014 05:13 PM, Markus Stockhausen wrote:
> Hello,
>
> we just build a new cluster with FC20 + virt-preview repos enabled.
> Idea behind that is to enable snapshot live merge feature. This
> seems to work quite well.
>
> The only culprit is the Windows activation. For some reasons the
> VM hardware of the old qemu 1.6/seabios 1.7.3 hypervisors is
> different to the new qemu 2.1/seabios 1.7.5. So the OS is no longer
> activated.
>
> We already activated the VMs twice. During first install on VMware
> and then afterwards after the migration to OVirt. I have no problem
> to reactivate them a third time. I have more fears that I must
> reactivate them with each new hypervisor generation. That can
> be quite a lot of phone calls.
>
> An interesting article from the Proxmox guys can be read here:
> http://forum.proxmox.com/archive/index.php/t-19743.html
> Conclusion of the discussion: After you go from qemu 1.7 to 2.1
> you can force the old hardware layout using -M pc-i440fx-1.7
>
> Looking at the qemu command line in OVirt I can see our VMs
> are fired up with pc-1.0,accel=kvm,usb=off - regardless of an
> old (FC20) or a new hypervisor (FC20+virt-preview). So I would
> guess that everything should work without a new reactivation.
>
> Any ideas?
>
> Markus
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
for .el6/.el7 we use the stable -m machines (-m rhel6.5.0, -m rhel-6.6.0, etc.)
fedora uses "pc" indeed. you can change it via config, but I don't know
fedora is keeping these stable for the other definitions / how to map them to cluster
levels
Change ClusterEmulatedMachines via engine-config to include the type suggested above
instead of pc. It would be more close to the hw we still use in 3.5 on el6/7
3656
days inactive
3657
days old
2 comments
3 participants
participants (3)
-
Itamar Heim -
Markus Stockhausen -
Michal Skrivanek