[Engine-devel] qemu machine type / datacenter machine version
I was playing around with ovirt-engine datacenter definitions and I seems that the capatibility version in the gui controls the qemu machine type specified (3.0 -> pc-0.14). I was wondering where that's configured setup. I grepped through my deployed system and saw a hit here: [root@f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine ovirt-engine-3.0.0_0001-1.2.fc16.x86_64 [root@f16-engine ovirt-engine]# grep -nri "pc-0.14" * db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); Is there any way to define different compatibiilty versions or edit that? If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14. Thoughts? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com
On 04/05/2012 06:27 PM, Ryan Harper wrote:
I was playing around with ovirt-engine datacenter definitions and I seems that the capatibility version in the gui controls the qemu machine type specified (3.0 -> pc-0.14). I was wondering where that's configured setup.
I grepped through my deployed system and saw a hit here:
[root@f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine ovirt-engine-3.0.0_0001-1.2.fc16.x86_64 [root@f16-engine ovirt-engine]# grep -nri "pc-0.14" * db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
Is there any way to define different compatibiilty versions or edit that? If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.
Thoughts?
check this and reply to it: http://lists.ovirt.org/pipermail/users/2012-March/001439.html
On 04/05/2012 08:14 PM, Itamar Heim wrote:
On 04/05/2012 06:27 PM, Ryan Harper wrote:
I was playing around with ovirt-engine datacenter definitions and I seems that the capatibility version in the gui controls the qemu machine type specified (3.0 -> pc-0.14). I was wondering where that's configured setup.
I grepped through my deployed system and saw a hit here:
[root@f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine ovirt-engine-3.0.0_0001-1.2.fc16.x86_64 [root@f16-engine ovirt-engine]# grep -nri "pc-0.14" * db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
Is there any way to define different compatibiilty versions or edit that? If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.
Thoughts?
check this and reply to it: http://lists.ovirt.org/pipermail/users/2012-March/001439.html
Since the topic was brought up, I have a long going request that oVirt will enable users to run multiple machine type versions on the same host (using the same qemu binary but providing a different -M compatibility level per VM). Is that on the roadmap? Thanks, Dor
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 04/06/2012 12:43 AM, Dor Laor wrote:
On 04/05/2012 08:14 PM, Itamar Heim wrote:
On 04/05/2012 06:27 PM, Ryan Harper wrote:
I was playing around with ovirt-engine datacenter definitions and I seems that the capatibility version in the gui controls the qemu machine type specified (3.0 -> pc-0.14). I was wondering where that's configured setup.
I grepped through my deployed system and saw a hit here:
[root@f16-engine ovirt-engine]# rpm -qf /usr/share/ovirt-engine ovirt-engine-3.0.0_0001-1.2.fc16.x86_64 [root@f16-engine ovirt-engine]# grep -nri "pc-0.14" * db-backups/tmprN1EDt.sql:12119:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); db-backups/tmpj4XRCI.sql:12138:INSERT INTO vdc_options (option_id, option_name, option_value, version) VALUES (236, 'EmulatedMachine', 'pc-0.14', '3.0'); dbscripts/upgrade/03_00_0530_update_EmulatedMachine_config_to_pc.sql:2:select
fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:7571:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:25529:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0'); dbscripts/create_db.sh.log:43487:select fn_db_update_config_value('EmulatedMachine','pc-0.14','3.0');
Is there any way to define different compatibiilty versions or edit that? If I've got a new end-point running qemu-kvm that doesn't have pc-0.14 defined (Say RHEL6.x) the machines won't lauch when you specific -M pc-0.14.
Thoughts?
check this and reply to it: http://lists.ovirt.org/pipermail/users/2012-March/001439.html
Since the topic was brought up, I have a long going request that oVirt will enable users to run multiple machine type versions on the same host (using the same qemu binary but providing a different -M compatibility level per VM).
Is that on the roadmap?
I assume once will start with cluster level enumeration/monitoring first which is the bug which i asked to open around this thread. then look at per vm level (I'm guessing best way to make this easy to manage at per-vm level would be to use 'cluster default' for most vm's) I understand choosing cpu model per vm may (mainly for -cpu best) also be desirable in some cases.
On 04/06/2012 06:00 AM, Itamar Heim wrote:
check this and reply to it: http://lists.ovirt.org/pipermail/users/2012-March/001439.html
Since the topic was brought up, I have a long going request that oVirt will enable users to run multiple machine type versions on the same host (using the same qemu binary but providing a different -M compatibility level per VM).
Is that on the roadmap?
I assume once will start with cluster level enumeration/monitoring first which is the bug which i asked to open around this thread. then look at per vm level (I'm guessing best way to make this easy to manage at per-vm level would be to use 'cluster default' for most vm's) I understand choosing cpu model per vm may (mainly for -cpu best) also be desirable in some cases.
Cpu model is a VM property. Setting anything beyond the least common denominator of your set of hardware hosts, may restrict using some of the older hosts as expected. btw: -cpu best is less flexible for non homogeneous set of hosts. Better use an explicit model for such environment. In theory the newest models should perform just as good as -best
participants (3)
-
Dor Laor -
Itamar Heim -
Ryan Harper