Re: [Engine-devel] proposing Arik Hadas as a maintainer of engine core

[Frantisek Kobzik]

+1!

- Original Message -
From: Michal Skrivanek michal.skriva...@redhat.com
To: Itamar Heim ih...@redhat.com, Livnat Peer lp...@redhat.com, Omer 
Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com, Yair 
Zaslavsky yzasl...@redhat.com, Maor Lipchuk mlipc...@redhat.com, Roy 
Golan rgo...@redhat.com, Eli Mesika emes...@redhat.com, Mike Kolesnik 
mkole...@redhat.com, Moti Asayag masa...@redhat.com, Shahar Havivi 
shav...@redhat.com, ov...@redhat.com, Allon Mureinik amure...@redhat.com
Cc: engine-devel@ovirt.org, in...@ovirt.org
Sent: Thursday, January 30, 2014 9:47:46 AM
Subject: [Engine-devel] proposing Arik Hadas as a maintainer of engine core

Dear engine-core maintainers,
I'd like to propose Arik Hadas as a maintainer of oVirt engine backend

Since he started with oVirt project in October 2012 he was working in various 
areas in engine core, demonstrated his abilities with more than 200 patches 
merged to engine master alone. Tons of migration related fixes, refactoring of 
legacy code, but also new complex features including complementary patches in 
UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements for 
VMTemplate operations)

Thanks in advance for your response.

Thanks,
michal
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support

[Frantisek Kobzik]

Hi guys,

I created a wiki page with the feature: 
http://www.ovirt.org/Features/Multiple_Consoles

It contains information about possible redesign of Engine-VDSM communication.
I'd appreciate if you take a look at it since it's not trivial change. 

I welcome opinions from both engine and vdsm devels.

Cheers,
F.

- Original Message -
From: Frantisek Kobzik fkob...@redhat.com
To: vdsm-de...@lists.fedorahosted.org
Sent: Monday, November 25, 2013 2:23:59 PM
Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support

Hi,

it's been some time since the original mail, so I'm sending updated information.


- Original Message -
From: Frantisek Kobzik fkob...@redhat.com
To: vdsm-de...@lists.fedorahosted.org
Sent: Thursday, November 7, 2013 11:47:46 AM
Subject: [vdsm] Multiple graphics framebuffers - VDSM support

Dear VDSM developers,

I'm working on a patch that allows running a VM with multiple graphics 
framebuffers. This is handy when you want to run a VM with both SPICE and VNC. 
It's a 3.4 feature and it will certainly need a change in vdsm.
Here is a list of changes in VDSM that are needed for this funcionality:
a, Sending graphics/video (engine-vdsm)
 - currently we send two things:
  1, display value (qxl/vnc [wat])
- vdsm uses this for determining if the graphics server is SPICE or VNC
- this attribute is not really correct - it mixes up semantics of graphic
  framebuffer and videocard together. I believe this attribute should only
  contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if
  you want both). if this the case, do you think we should rename the 
attribute
  to, let's say, 'graphics'? Is it even possible with regard to backward 
  compatibility? or should I reuse 'display' attribute?
  2, video device (json representation of the video card) - this is correct

b, Reporting graphics ports (vdsm-engine)
 - currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort')
 - if we want multiple framebuffers, we must report more ports (for VNC and 
   SPICE together that would mean 3 ports (2 for spice, one for vnc).
 - there are two possible solutions for this:
  1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort',
 'spiceSecurePort', 'vncPort' fields or some kind of two level dict:
{ protocol - secured/unsecured - portNumber }
  2, keep 'displayPort' and 'secureDisplayPort' and introduce new 
'additionalDisplayPort'
 This would be friendlier to backward compatibility, but it's extremely
 ugly because of unclear semantics of the fields (in case of SPICE+VNC
 'displayPort' and 'secureDisplayPort' would be related to SPICE, 
'additionalDisplayPort' would be the VNC port. In case of VNC only, the 
'displayPort' would be suddendly VNC port... ewww).

I'd be very happy if you share your opinion about these changes.

Cheers,
Franta.
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] RFE: SPICE and VNC graphics at the same time

[Frantisek Kobzik]

Dear devels,

I started working on a feature that allows user to run a VM with both SPICE and 
VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) 
from the video device (QXL/CIRRUS), which I think is wrong. These are two 
different things and should be treated separately. What I suggest is to split 
that configuration in vm_static into two fields:
 1, (already existing) Display type with values QXL or CIRRUS
 2, (new) Graphics types - enum or comma-separated string that indicates that 
the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that 
the type will be derived from the video device which is current behavior.

The feature would consist of three patches:
 - vdsm - add new field in vm.conf with information about graphics types of a 
vm.
 - engine backend - add graphics types to VM and corresponding entities, adjust 
xml rpc communication.
 - engine frontend - only adjust the ui.

The patches would be backwards compatible with older engine/vdsm versions.

There are some things that must be taken into account, mostly it's about 
differences in SPICE/VNC supported features (like multimonitors, single qxl, 
smartcard, migration...). e.g. if you run a vm with both graphic types together 
the engine should probably disallow some spice features. But this is more of an 
implementation detail.

Feel free to reply if you have anything to say about this feature.

Cheers,
Franta.


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time

[Frantisek Kobzik]

No, just two graphics .../ framebuffers.

- Original Message -
From: Omer Frenkel ofren...@redhat.com
To: Frantisek Kobzik fkob...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Wednesday, November 6, 2013 1:20:42 PM
Subject: Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time



- Original Message -
 From: Frantisek Kobzik fkob...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, November 6, 2013 11:33:28 AM
 Subject: [Engine-devel] RFE: SPICE and VNC graphics at the same time
 
 Dear devels,
 
 I started working on a feature that allows user to run a VM with both SPICE
 and VNC graphics [1]. In the engine we derive the graphics server type
 (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong.
 These are two different things and should be treated separately. What I
 suggest is to split that configuration in vm_static into two fields:
  1, (already existing) Display type with values QXL or CIRRUS
  2, (new) Graphics types - enum or comma-separated string that indicates that
  the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means
  that the type will be derived from the video device which is current
  behavior.
 

when choosing both, does this mean vm will have 2 video devices (cards)?

 The feature would consist of three patches:
  - vdsm - add new field in vm.conf with information about graphics types of a
  vm.
  - engine backend - add graphics types to VM and corresponding entities,
  adjust xml rpc communication.
  - engine frontend - only adjust the ui.
 
 The patches would be backwards compatible with older engine/vdsm versions.
 
 There are some things that must be taken into account, mostly it's about
 differences in SPICE/VNC supported features (like multimonitors, single qxl,
 smartcard, migration...). e.g. if you run a vm with both graphic types
 together the engine should probably disallow some spice features. But this
 is more of an implementation detail.
 
 Feel free to reply if you have anything to say about this feature.
 
 Cheers,
 Franta.
 
 
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/

[Frantisek Kobzik]

Hi,

sorry for that, should be fixed now.

Thanks,
F.

- Original Message -
From: Kiril Nesenko ki...@redhat.com
To: Frantisek Kobzik fkob...@redhat.com
Cc: engine-devel@ovirt.org, Eyal Edri ee...@redhat.com
Sent: Tuesday, July 2, 2013 7:27:43 AM
Subject: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/

Hello,

Seems like [1] brakes the job. Please fix.


[1] Commit fd872108a581a1a81a548f6c267fe9465780639a by Frantisek Kobzik
frontend: Make VNC implementation configurable from UI

- Kiril
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] 3.2 features for release notes

[Frantisek Kobzik]

oops, forgot to cc the others.

 checkbox at vm level to prevent accidental deletion
Simple protection from accidental VM or Template deletion. When user turns this 
protection on the entity (via checkbox in VM/Template dialog or using REST 
API), the engine does not permit its deletion.


- Original Message -
From: Itamar Heim ih...@redhat.com
To: Cheryn Tan cheryn...@redhat.com
Cc: engine-devel@ovirt.org, Federico Simoncelli fsimo...@redhat.com, Tomas 
Jelinek tjeli...@redhat.com, Roy Golan rgo...@redhat.com, Shahar 
Havivi shav...@redhat.com, Frantisek Kobzik fkob...@redhat.com, Arik 
Hadas aha...@redhat.com, Alona Kaplan alkap...@redhat.com, Igor 
Lvovsky ilvov...@redhat.com, Muli Salem msa...@redhat.com, Vojtech 
Szocs vsz...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron 
Fediuck dfedi...@redhat.com, oma...@redhat.com, Moran Goldboim 
mgold...@redhat.com, Daniel Erez de...@redhat.com, Tal Nisan 
tni...@redhat.com, Liron Aravot lara...@redhat.com, Eli Mesika 
emes...@redhat.com, Yaniv Bronheim ybron...@redhat.com, Juan Antonio 
Hernandez Fernandez jhern...@redhat.com, Alon Bar-Lev alo...@redhat.com, 
Yair Zaslavsky yzasl...@redhat.com, a...@us.ibm.com, Shireesh Anjal 
san...@redhat.com, Yaniv Dary yd...@redhat.com, Michael Pasternak 
mpast...@redhat.com
Sent: Thursday, January 24, 2013 4:30:07 PM
Subject: Re: [Engine-devel] 3.2 features for release notes

On 23/01/2013 23:47, Cheryn Tan wrote:
 Hi all,

 I'm preparing the oVirt 3.2 release notes, starting with the features listed 
 here: http://www.ovirt.org/OVirt_3.2_release-management#Features

 Can you please go through the list, and reply to this thread if:
 a) There are features being released for 3.2 which should be documented, but 
 are not on the list; or
 b) Some of the planned features on this list are not being released for 3.2; 
 or
 c) Some of the features on this list are being released for 3.2, but should 
 not be documented.

 For features which aren't on the wiki, please send a short description or 
 Bugzilla numbers of each feature.

 Please reply no later than Jan 28.

 Thank you very much for your help!
 Cheryn
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel


I think most of these made it to 3.2, i'll point fingers at others to 
give more details... (doesn't mean others weren't involved in them, just 
picked someone to give the details for release notes).

SSIA:
Add support for Opteron G5 (Seoul)
Add Support for Intel Haswell CPU
windows 8/12 - add os type
windows 8/12 - default in user portal should be rdp
(till we have spice support...)
expand tree by default with list of DCs

federico:
storage live migration

tomas:
Configure Smartcard for VM including Portal support
Allow e1000 to be selected as nic type for Windows VM dynamic

frantisek:
checkbox at vm level to prevent accidental deletion

shahar:
vm payload issues (with cd-rom)

Arik
Changing the name of the virtual machines, created from
a pool through web-admin-portal

Alona:
network as a main tab
network permissions
network main tab: search for networks (and api)
network main tab: show vms by logical network
hot-plug network - change networks on the fly

Igor:
hotplug nic hook

Muli:
display the VM interface IP per vnic
report ipv6 addresses from guest

vojtech:
ui plugins

Greg:
cluster policy on hyperthreads usage

Laszlo:
-cpu host

Ofri:
quota - add to resource tab in power user portal

moran:
ovirt-live

daniel erez:
slm: move multiple disks (one by one)
unicode enablement for OVF fields
disks subtab/api under storage domain

Tal:
delete disk on vm delete flag (for image vs. volume)

Liron:
move OVF update out of reconstruct master and all other flows as an
independent sync process

Eli:
inject events
bootstrap: fetch logs to engine
power management proxy (DC or cluster)
multiple fencing devices
add ilo2/ilo4 in text

Yaniv Bronhaim:
collect hardware (bios) information

juan:
engine-vdsm ssl session caching

michael kublin:
auto-recovery: last host in status up

Alon Bar-Lev:
bootstrap: install rhev-h without communication to
engine 443
bootstrap: pki: use PKCS#12 format to store keys
bootstrap: rewrite (ovirt-host-deploy)
bootstrap: rewrite (otopi)

Yair:
rhevm-manage-domains hardcodes the DC's address instead
of using DNS lookups

Yaniv Dary:
cloud provider report
Report Daily list of people logged into Spice consoles
and their activity 
add status of storage domain to dwh/reports
DC Dashboard should display Storage Domains count
single vm uptime - rhevm-reports should be able to
report uptime against virtual machines
Storage Inventory Report - New report

michael pasternak:
sdk - allow simultaneous connections to multiple servers
cli - disable output redirection to ease testing efforts
java sdk

Doron:
tuned profile for host

doron/adam:
not sure about status of vdsm-mom in 3.2?


shireesh - what about:
Forced removal

[Engine-devel] Attaching a console should be controllable

[Frantisek Kobzik]

Hi guys,

Just a simple question. I'm writing an engine counterpart for this vdsm feature:
https://bugzilla.redhat.com/show_bug.cgi?id=878459
http://gerrit.ovirt.org/#/c/9359

Long story short, it adds the possibility of controlling adding the virtio 
serial console to a VM.

I'm going to add a new column console_enabled to vm_static and a new field 
bool consoleEnabled to appropriate entities. I'm just worried about the 
naming of the column and the field - could I use these names? Isn't it 
confusing? I just want to avoid unneeded refactoring when the patch is done. 

Any feedback is welcome!

Thanks,
Frank
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel