Re: [Engine-devel] watchdog
On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: Hi, It is not really an optimization based only on console connection. In my opinion this should be a decision factor when determining which VM to migrate from an overloaded host. If it is a desktop and no console connection, then it is better candidate than a desktop with console connection or a server with or without console connection. Basically this logic would just want to minimize the pain caused by the short lag when a VM is live migrated. Can I assume that a Desktop is only used when a console is connected? connected by spice? by vnc to host or to guest? by rdp? by remote debugging to it from a remote machine, by someone developing on it with ssh, etc... i agree the general use case you are describing make sense, but i rather we model scheduling decisions directly if/where possible ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] oVirt history; now in starwars!
Here's a better way to see the project history: Engine http://starlogs.net/#oVirt/ovirt-engine VDSM http://starlogs.net/#oVirt/vdsm ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] watchdog
- Original Message - From: Itamar Heim ih...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel ovirt.org Sent: Sunday, April 14, 2013 5:04:55 PM Subject: Re: [Engine-devel] watchdog On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: Hi, It is not really an optimization based only on console connection. In my opinion this should be a decision factor when determining which VM to migrate from an overloaded host. If it is a desktop and no console connection, then it is better candidate than a desktop with console connection or a server with or without console connection. Basically this logic would just want to minimize the pain caused by the short lag when a VM is live migrated. Can I assume that a Desktop is only used when a console is connected? connected by spice? by vnc to host or to guest? by rdp? by remote debugging to it from a remote machine, by someone developing on it with ssh, etc... i agree the general use case you are describing make sense, but i rather we model scheduling decisions directly if/where possible Some parts of this thread are looking for perfection and on the way creating additional tasks and reviewing cycles that are only remotely related to the watchdog device; Yes, we should try and reduce the existing differentiation between desktop and a server. No, this feature is not about closing that gap. Watchdog device is about handling guest crash. I strongly suggest that merging desktop and server dialogues will be done as a different feature. The watchdog feature will take one step in the 'right' direction- adding the (currently missing) HA tab into the desktop dialog based on current design. Doron ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] watchdog
On 04/14/2013 05:59 PM, Doron Fediuck wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel ovirt.org Sent: Sunday, April 14, 2013 5:04:55 PM Subject: Re: [Engine-devel] watchdog On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: Hi, It is not really an optimization based only on console connection. In my opinion this should be a decision factor when determining which VM to migrate from an overloaded host. If it is a desktop and no console connection, then it is better candidate than a desktop with console connection or a server with or without console connection. Basically this logic would just want to minimize the pain caused by the short lag when a VM is live migrated. Can I assume that a Desktop is only used when a console is connected? connected by spice? by vnc to host or to guest? by rdp? by remote debugging to it from a remote machine, by someone developing on it with ssh, etc... i agree the general use case you are describing make sense, but i rather we model scheduling decisions directly if/where possible Some parts of this thread are looking for perfection and on the way creating additional tasks and reviewing cycles that are only remotely related to the watchdog device; Yes, we should try and reduce the existing differentiation between desktop and a server. No, this feature is not about closing that gap. Watchdog device is about handling guest crash. I strongly suggest that merging desktop and server dialogues will be done as a different feature. The watchdog feature will take one step in the 'right' direction- adding the (currently missing) HA tab into the desktop dialog based on current design. 1. it is a different task. 2. i'm suggesting you can drop the code doing that distinction for the watchdog in this patch. Doron ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Hi Doron and Ofri, Thanks for your reply, here is some other question. ii. When adding a host into the trusted cluster, the host will be attested via OAT service, only trusted hosted can be added. Would you also kindly tell me if there is any mandatory logic check when adding a host into a cluster, so we can also put attestation logic with these mandatory check together? Some example or code location is better. Thanks a lot. Best Regards, Dave Chen -Original Message- From: Doron Fediuck [mailto:dfedi...@redhat.com] Sent: Wednesday, April 10, 2013 8:03 PM To: Ofri Masad Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Gang Wei gang@intel.com Cc: Wei D Chen wei.d.c...@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Doron Fediuck dfedi...@redhat.com Sent: Wednesday, April 10, 2013 2:23:57 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi, answers inside the mail body. - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Gang Wei gang@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Ofri Masad oma...@redhat.com Sent: Wednesday, April 10, 2013 12:12:26 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Adding Ofri to answer your questions. - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Gang Wei gang@intel.com, Doron Fediuck dfedi...@redhat.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com Sent: Wednesday, April 10, 2013 6:31:05 AM Subject: RE: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Doron, iii.Then periodic trust check will be added into background process for all existing hosts, once becoming non-trusted, mark it as non-operational. - [Dave] Would you give me some details about the “background process” mentioned in our sync up meeting? What’s the process and where is related code? The use Quartz Job to scheduled background processes. An example can be found in: ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: 222) This code calls a method that is located in: ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin e/core/bll/quota/QuotaManager.java (Line: 1000) the @OnTimerMethodAnnotation annotation and the unique job name connects the two in runtime. The job can query the attestation server for all the host and then set untrusted hosts to Non-Operational. the best way would be to call SetNonOperationalVdsCommand with a new NonOperationalReason. This command tries to migrate all VMs from the host and then set it non operational. (We need to think about non-migrational VMs - should we close those VMs or keep the host running) One more thing you may want to consider; If we get a positive response for a host which is currently non-operational, issue an activate command to try and make it operational again. Alternatively, you may decide not to handle it, assuming untrusted hosts can only be activated manually (see below Ofri's response on activating a host). iv. If admin fixed the non-operational node and try to switch it to operational mode again, a trust check will happen to gate the switching. - [Dave] If there is a button provided from UI for checking the logic? or we need add an extra-button for attestation check only? In the UI we already have the Activate option. What still needs to be added is the check with the attestation provider to make sure that if the cluster is defined 'Trusted'. If so, only trusted host will succeed in the activate command (and, of course, a proper Audit Log error in case the host failed to activate due to trust issue. the correct place to add this check would be in: ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt /engine/core/vdsbroker/VdsManager.java:activate() this is where the re-activation process begins. Thanks very much. Best Regards, Dave Chen ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
