Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen vla...@yahoo.com.au To: Itamar Heim ih...@redhat.com, Fabian Deutsch fdeut...@redhat.com Cc: users users@ovirt.org Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
On 04/08/2014 06:58 PM, Doron Fediuck wrote: - Original Message - From: Paul Jansen vla...@yahoo.com.au To: Itamar Heim ih...@redhat.com, Fabian Deutsch fdeut...@redhat.com Cc: users users@ovirt.org Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it? seems like another case of feature level negotiatio. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen To: Itamar Heim Fabian Deutsch Cc: users Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it? Well, when you choose to migrate a VM under Vmware's Vcenter you can choose to migrate either the host or the datastore. For whichever one you choose there is a validation step to check the you are able to perform the migration (ie: capabilities of the host). I can see in ovirt that we are showing the KVM version on hosts. This matches the package version of the qemu-kvm package (or the qemu-kvm-rhev package if installed?). Could we have some sort of a cutoff point where we know which versions of KVM (ie: qemu-kvm or qemu-kvm-rhev) support the storage migration feature, and if a version is found that doesn't match the required heuristics we just indicate the the validation process for the migration has failed? We could provide some small output indicating why it has failed. Does this sound like a reasonable approach? Is there any news on discussions with the CentOS people as to where a qemu-kvm-rhev package could be hosted (that we could then take advantage of)? If the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sorted out in the short term, I did some quick calculations last night and it seems based on previous EL point releases (this is hardly scientific I know) we are not likely to see an EL 6.6 for another few months. We may see an EL7.0 before that timeframe. Ovirt can obviously jump on new EL releases to use as hosts in a new ovirt version but it seems this option is still some time away. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
On 04/09/2014 06:41 AM, Paul Jansen wrote: - Original Message - From: Paul Jansen To: Itamar Heim Fabian Deutsch Cc: users Sent: Monday, April 7, 2014 3:25:19 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. Paul, this is something that vdsm needs to report to the engine, so the engine will know what is / isn't supported. It's a bigger request as today we're mostly based on cluster compatibility level. Additionally it is possible to mix .el hosts with nodes with old (non -rhev) nodes. Each of these cases will break live-storage migration. How do you suggest to mitigate it? Well, when you choose to migrate a VM under Vmware's Vcenter you can choose to migrate either the host or the datastore. For whichever one you choose there is a validation step to check the you are able to perform the migration (ie: capabilities of the host). I can see in ovirt that we are showing the KVM version on hosts. This matches the package version of the qemu-kvm package (or the qemu-kvm-rhev package if installed?). Could we have some sort of a cutoff point where we know which versions of KVM (ie: qemu-kvm or qemu-kvm-rhev) support the storage migration feature, and if a version is found that doesn't match the required heuristics we just indicate the the validation process for the migration has failed? We could provide some small output indicating why it has failed. Does this sound like a reasonable approach? Is there any news on discussions with the CentOS people as to where a qemu-kvm-rhev package could be hosted (that we could then take advantage of)? If the hosting of an updated qemu-kvm (or qemu-kvm-rhev) is not sorted out in the short term, I did some quick calculations last night and it seems based on previous EL point releases (this is hardly scientific I know) we are not likely to see an EL 6.6 for another few months. We may see an EL7.0 before that timeframe. Ovirt can obviously jump on new EL releases to use as hosts in a new ovirt version but it seems this option is still some time away. Paul - just to clarify, you are mentioning versions all the time, but qemu-kvm doesn't have these features regardless of version. you need the qemu-kvm-rhev package, which we hope to get into the CentOS cloud or virt SIG, and for now is available via jenkins.ovirt.org based on the centos srpm. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
Am Sonntag, den 06.04.2014, 11:57 -0400 schrieb Doron Fediuck: - Original Message - From: Paul Jansen vla...@yahoo.com.au To: users users@ovirt.org Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev? I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake? Hey, yeah - that is also my concern. oVirt node has a mechanism (in master) to expose that features are present or not, but I don't know if vdsm has the capability to pass this on to Engine, and if Engine has the logic to detect incompatabilities based on the underlying qemu-kvm-rhev version. Greetings fabian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen: My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS. If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. The Fedora based images are at least for now available from Jenkins. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. What is this ovirt hypervisor package you mention? - fabian It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
I'm going to try top posting this time to see if it ends up looking a bit better on the list. By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. From: Fabian Deutsch To: Paul Jansen Cc: Doron Fediuck; users Sent: Monday, 7 April 2014 5:20 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen: My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS. If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. The Fedora based images are at least for now available from Jenkins. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. What is this ovirt hypervisor package you mention? - fabian It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt?___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. Greetings fabian __ From: Fabian Deutsch To: Paul Jansen Cc: Doron Fediuck; users Sent: Monday, 7 April 2014 5:20 PM Subject: Re: [Users] node spin including qemu-kvm-rhev? Am Sonntag, den 06.04.2014, 19:15 -0700 schrieb Paul Jansen: My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? EL7 is one point, but there were users also asking for Fedora based Nodes and we use Fedora for development, to have stable Nodes (at some point later) based on CentOS. If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. The Fedora based images are at least for now available from Jenkins. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. What is this ovirt hypervisor package you mention? - fabian It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. just to make sure there is no confusion, ovirt supports two types of nodes: - plain fedora/rhel/centos - engine will deploy vdsm and friends on it when added - ovirt-node - engine will only register it, it already comes with all needed packages. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
On 04/07/2014 11:46 AM, Fabian Deutsch wrote: Hey Paul, Am Montag, den 07.04.2014, 01:28 -0700 schrieb Paul Jansen: I'm going to try top posting this time to see if it ends up looking a bit better on the list. you could try sending text-only emails :) By the 'ovirt hypervisor packages' I meant installing the OS first of all and then making it into an ovirt 'node' by installing the required packages, rather than installing from a clean slate with the ovirt node iso. Sorry if that was a bit unclear. Okay - thanks for the explanation. In general I would discourage from installing the ovirt-node package ona normal host. If you still want to try it be aware that the ovirt-node pkg might mess with your system. I'm pretty sure we are on the same page here. I just checked the ovirt 'quickstart' page and it calls the various hypervisor nodes 'hosts'. ie: Fedora host, EL, host, ovirt node host. If the ovirt node included the qemu-kvm-rhev package - or an updated qemu-kvm - it would mean that both ovirt node hosts and fedora hosts could both support live storage migration. It would only be EL hosts that do not support that feature at this stage. We could have a caveat in the documentation for this perhaps. Fabian, were you think thinking that if not all 'hosts' supported live migration that the cluster could disable that feature? Based on capabilities that the hosts would expose to the ovirt server? This would be another way of avoiding the confusion. Thanks guys for the great work you are doing with ovirt. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen vla...@yahoo.com.au To: users users@ovirt.org Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev? I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] node spin including qemu-kvm-rhev?
- Original Message - From: Paul Jansen vla...@yahoo.com.au To: users users@ovirt.org Sent: Wednesday, April 2, 2014 11:38:29 AM Subject: [Users] node spin including qemu-kvm-rhev? I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? Sounds reasonable as long as you understand mix and match will become an issue. The questions is how do we differentiate between the nodes to make sure no one mixes them by mistake? My mail client might mangle the bottom-posting here, so we'll see how it goes. I saw a post from Fabian that he had re-enabled jenkins builds of the node image based on Fedora 19/20 (but not yet including the VDSM plugin). Presumably the main goal of this is to ensure that things in node land are OK for an upcoming spin based on EL7? If ovirt does go back to having Fedora and EL based node images in the short term it would mean that live migration will work on the Fedora images. If it was also decided to allow the EL based node image to include the recompiled qemu-kvm-rhev package the Ovirt release notes could then say that when using an ovirt node image live migration is supported, as is when a fedora install has the ovirt hypervisor packages installed. It would only be that an EL based system - built up to then also include the ovirt hypervisor packages - that live migration would not be supported - at this stage. This can change when the details are further worked out with the Centos people about how the updated qemu-kvm packages will be hosted and made available. In the meantime, people that want to set things up so that live migration is there can do so. Once live migration is in place I think it would be interesting to try and find out from people interested (or already testing ovirt) that have VMware backgrounds/experience what they think is the the largest outstanding issue feature wise when comparing ovirt to Vcenter. What would stop them from migrating from vcenter to ovirt? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] node spin including qemu-kvm-rhev?
I understand that there are ongoing discussions with the Centos people regarding a suitable home for recompiled qemu-kvm packages. Given that the ovirt node is our own spin, is there any reason why that couldn't include the recompiled qemu-kvm packages that will then allow us to use live snapshots and do live migrations? Itamar recently mentioned that we already build these via a jenkins task. Nodes built on top of a Centos install will still be an issue but I think its reasonable that the ovirt-node iso could include these custom packages. This way we don't have to potentially wait until 3.4.1 or 3.5 to get the live snapshot/migration features. The caveat would be that these features would only be supported if the nodes were all ovirt node iso based. What are people's thoughts? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
