[RFC]about the implement of text-based console
by Xu He Jie
Hi,
I submited a patch for text-based console
http://gerrit.ovirt.org/#/c/7165/
the issue I want to discussing as below:
1. fix port VS dynamic port
Use fix port for all VM's console. connect console with 'ssh vmUUID@ip
-p port'.
Distinguishing VM by vmUUID.
The current implement was vdsm will allocated port for console
dynamically and spawn sub-process when VM creating.
In sub-process the main thread responsible for accept new connection and
dispatch output of console to each connection.
When new connection is coming, main processing create new thread for
each new connection. Dynamic port will allocated
port for each VM and use range port. It isn't good for firewall rules.
so I got a suggestion that use fix port. and connect console with
'ssh vmuuid@hostip -p fixport'. this is simple for user.
We need one process for accept new connection from fix port and when new
connection is coming, spawn sub-process for each vm.
But because the console only can open by one process, main process need
responsible for dispatching console's output of all vms and all connection.
So the code will be a little complex then dynamic port.
So this is dynamic port VS fix port and simple code VS complex code.
Thanks!
11 years, 4 months
vdsm API schema
by agl＠us.ibm.com
For the past few weeks I have been working on creating a schema that fully
describes the vdsm API. I am mostly finished with that effort and I wanted to
share the results with the team. Attached are two files: the raw schema and an
html document with cross-linked type information.
This should already be useful in its current form, but I have bigger plans. I
would first like to get help to correct errors in the schema. Then, I will
start the process of writing a code generator that will create C/gObject code
that we can compile into a libvdsm with language bindings for python, java, etc.
Please take a look at the attached files and let me know what you think?
P.S. I tried to attach these to the oVirt Wiki, but they are not permitted file
types.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 6 months
oVirt Workshop Europe 2012: Call For Participation
by workshop-pc＠ovirt.org
=================================================================
oVirt Workshop Europe 2012: Call For Participation
November 7-9, 2012 - Hotel Fira Palace - Barcelona, Spain
(All submissions must be received before midnight Sep 14th, 2012)
=================================================================
The oVirt Project is an open virtualization project for anyone who cares
about Linux-based KVM virtualization. Providing a feature-rich server
virtualization management system with advanced capabilities for hosts
and guests, including high availability, live migration, storage
management, system scheduler, and more. By open we mean open source &
open governance, done right.
During this workshop you’ll learn about the technical background and
direction of the oVirt project. You’ll meet the developers, and have an
opportunity to see and dive into the code right away. The workshop is
open to all who want to use, get involved with, or learn about the
comprehensive open virtualization management platform, oVirt. The
sessions cover the technical projects details, governance, getting
involved, usage, and much more. If you have any interest in an Open
Virtualization Management platform, this workshop is for you!
We are excited to announce that this oVirt Workshop will be held in
conjunction with the KVM Forum.
http://events.linuxfoundation.org/events/kvm-forum/
The KVM Forum and oVirt Workshop are co-located with the Linux
Foundation's 2012 LinuxCon Europe in Barcelona, Spain.
oVirt Workshop attendees will be able to attend KVM Forum sessions and
are eligible to attend LinuxCon Europe for a discounted rate.
http://events.linuxfoundation.org/events/kvm-forum/register
We invite you to lead part of the discussion by submitting a speaking
proposal for oVirt Workshop 2012.
http://events.linuxfoundation.org/cfp
Suggested topics:
- community use case/stories
- roadmaps
- deep dives into features/areas
- deep dives into code/debugging/tuning
- integration and extensions
- components: engine, vdsm, node, sdk/cli, reports, mom, guest agent, etc.
- subjects: network, storage, vm life cycle, scheduling & sla, gluster, etc.
- packaging, installation and distributions
- community infrastructure and services
SUBMISSION REQUIREMENTS
Abstracts due: Sep 14th, 2012
Notification: Sep 28th, 2012
Please submit a short abstract (~150 words) describing your presentation
proposal. In your submission please note how long your talk will take.
Slots vary in length up to 45 minutes. Also include in your proposal
the proposal type -- one of:
- technical talk
- end-user talk
- birds of a feather (BOF) session
Submit your proposal here:
http://events.linuxfoundation.org/cfp
You will receive a notification whether or not your presentation proposal
was accepted by Sep 14th.
END-USER COLLABORATION
One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.
If you are using oVirt in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user collaboration proposal. As an
end user, this is a unique opportunity to get your input to developers.
BOF SESSION
We will reserve some slots in the evening after the main conference
tracks, for birds of a feather (BOF) sessions. These sessions will be
less formal than presentation tracks and targetted for people who would
like to discuss specific issues with other developers and/or users.
If you are interested in getting developers and/or uses together to
discuss a specific problem, please submit a BOF proposal.
LIGHTNING TALKS
In addition to submitted talks we will also have some room for lightning
talks. These are short (5 minute) discussions to highlight new work or
ideas that aren't complete enough to warrant a full presentation slot.
Lightning talk submissions and scheduling will be handled on-site at
oVirt Workshop.
HOTEL / TRAVEL
The oVirt Workshop Europe 2012 will be held in Barcelona, Spain at the
Hotel Fira Palace.
http://events.linuxfoundation.org/events/kvm-forum/hotel
Thank you for your interest in oVirt. We're looking forward to your
submissions and seeing you at the oVirt Workshop Europe 2012 in November!
Thanks,
your oVirt Workshop Europe 2012 Program Commitee
Please contact us with any questions or comments.
workshop-pc(a)ovirt.org
11 years, 7 months
[RFC] GlusterFS domain specific changes
by M. Mohan Kumar
We are developing a GlusterFS server translator to export block devices
as regular files to the client. Using block devices to serve VM images
gives performance improvements, since it avoids some file system
bottlenecks in the host kernel. Goal is to use one block device(ie file
at the client side) per VM image and feed this file to QEMU to get the
performance improvements. QEMU will talk to glusterfs server directly
using libgfapi.
Currently we support only exporting Volume groups and Logical
Volumes. Logical volumes are exported as regular files to the client. In
GlusterFS terminology a volume capable of exporting block devices is
created by specifying the 'Volume Group' (ie VG in Logical Volume
management). Block Device translator(BD xlator) exports this volume
group as a directory and LVs under it as regular files. In the gluster
mount point creating a file results in creating a logical volume,
removing a file results in removing logical volume etc.
When a GlusterFS volume enabled with BD xlator is used, directory
creation in that gluster mount path is not supported because directory
maps to Volume groups in BD xlator. But it could be an issue in VDSM
environment when a new VDSM volume is created for GlusterFS domain, VDSM
mounts the storage domain and creates directories under that and create
files for vm image and other uses (like meta data).
Is it possible to modify this behavior in VDSM to use flat structure
instead of creating directories and VM images and other files underneath
it? ie for GlusterFS domain with BD xlator VDSM will not create any
directory and only creates all required files under the mount point
directory itself.
Note:
Patches to enable exporting block devices as regular files are available
in Gluster Gerrit system
http://review.gluster.com/3551
11 years, 7 months
[RFC] Implied UUIDs in API
by smizrahi＠redhat.com
Hi, in the API a lot of IDs get passed around are UUIDs.
The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
It's another restriction we can remove from the interface simplifying the code and the interface.
Just to be clear I'm not saying that we should stop using UUIDs.
For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
If for some reason we choose to change the format of task IDs. There will be no need to change the interface.
The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values.
11 years, 7 months
Jenkins build failure for change that adds build dependencies
by agl＠us.ibm.com
Hi,
My change, http://gerrit.ovirt.org/#/c/7516/ adds the following build
dependencies. Since they are not installed on the system running patch
verification tests I am getting build failures. Can we get these packages
installed on the testing host(s) please?
+BuildRequires: gobject-introspection-devel
+BuildRequires: glib2-devel
+BuildRequires: json-glib-devel
+BuildRequires: vala
+BuildRequires: libgee-devel
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 7 months
AUTO: Yih-Herng Chuang/Seattle/IBM is out of the office until 12/17/2001. (returning 08/31/2012)
by Yih-Herng Chuang
I am out of the office until 08/31/2012.
For tech issues, please contact my team lead Doug Jans. For others, please
contact my manager Carol Roth. I will respond your email when I am back to
work.
Note: This is an automated response to your message "vdsm-devel Digest,
Vol 15, Issue 30" sent on 08/28/2012 6:00:06.
This is the only notification you will receive while this person is away.
11 years, 8 months
Problem hotplugging an Interface
by Itzik Brown
Hi,
I installed vdsm latest git version.
When trying to hotplug a new NIC the operation fails.
Here are some lines from vdsmd.log
Thread-480::DEBUG::2012-08-15 11:50:52,150::libvirtvm::1398::vm.Vm::(hotplugNic) vmId=`54028863-6910-44ac-a843-a61083e65b70`::Hotplug NIC xml: <interface type="bridge">
<mac address="00:1a:4a:1e:31:0c"/>
<model type="virtio"/>
<source bridge="ovirtmgmt"/>
</interface>
Thread-480::ERROR::2012-08-15 11:50:52,297::libvirtvm::1403::vm.Vm::(hotplugNic) vmId=`54028863-6910-44ac-a843-a61083e65b70`::Hotplug failed
Traceback (most recent call last):
File "/usr/share/vdsm/libvirtvm.py", line 1401, in hotplugNic
self._dom.attachDevice(nicXml)
File "/usr/share/vdsm/libvirtvm.py", line 487, in f
ret = attr(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 400, in attachDevice
if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self)
libvirtError: internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging
OS: Fedora17
VDSM Packages: vdsm-4.10.0-0.313.git8bedc7e.fc17.x86_64 vdsm-xmlrpc-4.10.0-0.313.git8bedc7e.fc17.noarch vdsm-python-4.10.0-0.313.git8bedc7e.fc17.x86_64
Libvirt: libvirt-0.9.11.4-3.fc17.x86_64
QEMU: qemu-common-1.0.1-1.fc17.x86_64
Trying to attach the NIC using virsh fails as well:
virsh -c qemu+tcp://localhost/system attach-device vm1 --file /tmp/1.xml
error: Failed to attach device from /tmp/1.xml
error: internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging
When running with VDSM from ovirt repository with the following packages the hotplug of the NIC works:
vdsm-xmlrpc-4.10.0-6.fc17.noarch
vdsm-4.10.0-6.fc17.x86_64
vdsm-python-4.10.0-6.fc17.x86_64
Please advise,
Itzik
11 years, 8 months
Meeting minutes
by Dan Kenigsberg
Today we had a quiet, civilized, meeting where the following points were
raised:
- For a week, I've missed a report by Itzik about vdsm starting to send
<feature><acpi/> tag to libvirt when asked to.
https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-August/001335.html
Could this be related to http://gerrit.ovirt.org/6846 or
http://gerrit.ovirt.org/5369 ?
I suppose not, but maybe the authors can help me understand what's going on
here.
- Robert: about to release a Jenkins job, that compiles rpm per patch, to help
people test patches.
- Federico: agrees to look into why we get fishy
Exception RuntimeError: RuntimeError('cannot notify on un-acquired lock',) in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored
messages from the unit tests, even though it is not due to his recent RLock
work.
- Adam: libvdsm still has few shortcomings; plans to enumerate known issue by
tomorrow, and push to the world. Asks that Federico reviews his autobuild
changes.
- Saggi: when that's out, will work on Java binding for the benefit of Engine.
Dan: we must get Engine's consent for libvdsm.
- We need to set the priorities for ovirt-3.2 release, planned for November, to
fit into Fedora 19. Adam and Dan thinks that libvsdm is high on that list.
- Deepack: requests review for his gluster work
http://gerrit.ovirt.org/#/c/6856/
- Adam: mom integration: VMs are to have policy tags, such as
Gold/ Silver/ Bronze to be enforced by MoM.
- Robert: should we auto-test mom? Adam to add `make check` with basic stuff
such as pyflakes.
- Dan: should we abandon old patches? Federico: no, people may want they
Work-in-Progress patches to stay around and inspire others. A nag mail
for a patch that is not abandoned and not advancing anywhere is more
reasonable.
If someone has some time to put into gerrit scripting, I won't mind to
see such a nag bot. It would help we separate important patches that
were somehow forgotten by their author/reviewers and stuff that should
probably be recycled.
- I'm pretty sure we had more participants, and more issues raised.
Please send a patch to this email with corrections/ additions.
Regards,
Dan.
11 years, 8 months
