[vdsm] oVirt Updates - November 2013
Case Studies - Dave Neary just published his interview with Martin Goldstone and Gary Lloyd, system administrators at the Keele university http://www.ovirt.org/Keele_University_case_study (we'd be happy to have more case studies, please contact Dave if you are willing to do one - its mostly just an interview with him) oVirt 3.3 - 3.3.1 with a slew of updates is finally out. http://www.ovirt.org/OVirt_3.3.1_release_notes - 3.3.2 beta planned once we GA 3.3.1. - sample scheduler plugins available here http://www.ovirt.org/External_Scheduler_Samples oVirt 3.4 - planning is on going, please join and help make oVirt better http://lists.ovirt.org/pipermail/users/2013-October/017451.html (clearly, only items with devel owners will make it) Conferences - Einav presented at an oVirt booth in LISA 2013 (Washington, DC) - Fosdem virt IaaS devroom CFP[1] is open till December 1st http://bit.ly/1gMXdUH We also requested a stand/table/booth to demo oVirt (we'd love if oVirt users visiting Fosdem would volunteer to help man the stand/demo) - KVM Forum/CloudOpen sessions available http://www.ovirt.org/KVM_Forum_2013 Cross Distro - guest agent packages are now available for OpenSUSE 12.3, 13.1 and Factory, and SLES 11 SP3. (thanks Vinzenz for pushing and René for testing) - Ubuntu packages pushed by Zhou Zheng Sheng. - How To: Get oVirt 3.2 All-In-One working on Scientific Linux 6.4 (With fixes!) http://bit.ly/17BstPj Related - How to manage multiple nodes with oVirt (Japanese) http://lab.space-i.com/?p=1252 - oVirt node has a new plugin, allowing it to be used for The Foreman host discovery http://www.youtube.com/watch?v=V8TugleqF64 - how to use virt-sysprep with oVirt/RHEV http://bit.ly/1hy54Xx - script to easily move VMs by name from export domain https://github.com/ppiersonbt/ovfmaker - some oVirt and Dell Equalogic issues discussions http://dell.to/1gN3TlX http://bit.ly/1cXrIH2 - Intro to oVirt on Fedora (Spanish) http://www.itrestauracion.com.ar/?p=1505 - Christophe Fergeau published libgovirt 0.3.0 (storage domains, cd-rom and certificate handling improvements) http://red.ht/HVl4U2 - helper script by Humble to print list of VMs and their nic/mac/ip http://bit.ly/1ePpMjF - Want to play with oVirt Neutron and GRE Tunneling? http://www.ovirt.org/OVirt_Neutron_GRE_Integration_-_How_To - How To: Install rhev-agents on Scientific Linux 6x http://bit.ly/1cZRydo - How To: Convert a server running on VMware ESXi 5x to oVirt 3.2 http://bit.ly/17x2X1O ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Multiple graphics framebuffers - VDSM support
Hi Martin, thanks for feedback (details below).
I'll try to bump this thread with new information later today.
- Original Message -
From: Martin Polednik mpole...@redhat.com
To: Frantisek Kobzik fkob...@redhat.com
Cc: vdsm-devel@lists.fedorahosted.org
Sent: Friday, November 8, 2013 5:48:02 PM
Subject: Re: [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
In order to keep backwards compatibility after rename, engine would have to
send different command to newer/older VDSMs as older VDSM has no code to
understand
different keyword - I'd say keep the name display.
Yes, in this case engine would make that decision based on cluster
compatibility version.
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).
Same difficulty as previous case but on engine side: unless older engine can
process new keywords, our best and only backwards compatible choice is adding
a new field.
I've got the same opinion.
Also what won't remain unaffected is migration: migrating VM with multiple
framebuffers to older VDSM will afaik require patching the config causing
VM to only run with one framebuffer, possibly losing the information that
another was attached (in case of another migration to new VDSM).
Migration shouldn't be the issue IMHO. Migration of a vm with multiple
graphics .../ to old vdsm shouldn't happen. There some situation however
that must be taken into account (like 'new' host existing within cluster with
3.3 compatibility version etc.).
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2
An important feature of ovirt-3.3 has not made it to the ovirt-3.3.0 deadline: http://www.ovirt.org/Features/Self_Hosted_Engine. It would allow to run Engine as a VM on top one of the hosts controlled by itself, saving resources and allowing high availablity out-of-the-box. The feature was not ready on time for the ovirt-3.3.0 release but now its Engine-side patches are merged, and its Vdsm-side patches are pending aproval for entry into Vdsm's stable branch. http://gerrit.ovirt.org/20189 http://gerrit.ovirt.org/20190 http://gerrit.ovirt.org/20191 http://gerrit.ovirt.org/20192 http://gerrit.ovirt.org/20193 http://gerrit.ovirt.org/20194 http://gerrit.ovirt.org/20209 http://gerrit.ovirt.org/20300 http://gerrit.ovirt.org/21357 I suggest to take the pending patches into the ovirt-3.3 branch, and ship ovirt-3.3.2 with this feature enabled. We shall not release ovirt-3.3.2 before we are assured by quality engineering that we have no regression to main Vdsm code. If we do not receive this green light, and there's urgency to release ovirt-3.3.2, we'd fork and ship 3.3.2 only with the urgent fixes. Any objections? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
