[oVirt 3.6 Localization Question #19] "The selected proxy Host must be in the destination Storage Pool"
by Yuko Katabami
This is a multi-part message in MIME format.
--------------080709010200010402090907
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hello again,
Here is another question,
*
File:***AppErrors
*Resource ID:***ACTION_TYPE_FAILED_VDS_NOT_IN_DEST_STORAGE_POOL
*String:***Cannot ${action} ${type}. The selected proxy Host must be in
the destination Storage Pool.
*Question: *In my language, translation for the word "destination may
have to be changed depending on the action (i.e. migrate, move,
import/export, copy, clone etc).
What action is applicable in this case?
Thank you,
Yuko
--------------080709010200010402090907
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello again,<br>
<br>
Here is another question,<br>
<b><br>
File:</b><b> </b>AppErrors<br>
<div class="moz-signature"><b>Resource ID:</b><b> </b>ACTION_TYPE_FAILED_VDS_NOT_IN_DEST_STORAGE_POOL<br>
<b>String:</b><b> </b>Cannot ${action} ${type}. The selected
proxy Host must be in the destination Storage Pool.<br>
<b>Question: </b>In my language, translation for the word
"destination may have to be changed depending on the action (i.e.
migrate, move, import/export, copy, clone etc).<br>
What action is applicable in this case?<br>
<br>
Thank you,<br>
<br>
Yuko<br>
</div>
</body>
</html>
--------------080709010200010402090907--
7 years, 11 months
[oVirt 3.6 Localization Question #17] "unified affinity group"
by Yuko Katabami
This is a multi-part message in MIME format.
--------------090005010203070603030901
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hello all,
I am currently updating the oVirt 3.6 UI translations with other
translators and would like to ask you the following question:
*
File:*** ApplicationConstants
*Resource ID:***ACTION_TYPE_FAILED_AFFINITY_RULES_COLLISION
*String:*** Affinity Group collision detected in unified affinity group:
${UnifiedAffinityGroups}
and negative affinity group:
${negativeAR}
*Question: *Is "unified affinity group" referring to "positive affinity
group"? (the term is used in http://www.ovirt.org/Features/VM-Affinity
and a check box in the New/Edit Affinity Group window)
Is this error message is shown when there is a conflict between unified
(positive?) affinity group and negative affinity group is found?
Thanks in advance,
Yuko Katabami
--------------090005010203070603030901
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello all,<br>
<br>
I am currently updating the oVirt 3.6 UI translations with other
translators and would like to ask you the following question:<br>
<b><br>
File:</b><b> </b> ApplicationConstants<br>
<div class="moz-signature"> <b>Resource ID:</b><b> </b>ACTION_TYPE_FAILED_AFFINITY_RULES_COLLISION<br>
<b>String:</b><b> </b> Affinity Group collision detected in
unified affinity group:<br>
${UnifiedAffinityGroups}<br>
and negative affinity group:<br>
${negativeAR}<br>
<b>Question: </b>Is "unified affinity group" referring to
"positive affinity group"? (the term is used in
<a class="moz-txt-link-freetext" href="http://www.ovirt.org/Features/VM-Affinity">http://www.ovirt.org/Features/VM-Affinity</a> and a check box in the
New/Edit Affinity Group window)<br>
Is this error message is shown when there is a conflict between
unified (positive?) affinity group and negative affinity group is
found?<br>
<br>
Thanks in advance,<br>
<br>
Yuko Katabami<br>
</div>
</body>
</html>
--------------090005010203070603030901--
7 years, 11 months
Get involved in oVirt project! Summer edition
by Sandro Bonazzola
Hi,
Summer is here and vacations are near! Have you got some free time and do you want to get involved in oVirt project?
Do you like the idea of having fresh disk images of recent distribution in oVirt Gluster repository?
You can help us by testing existing online images (like https://getfedora.org/en/cloud/download/) ensuring they works with cloud-init
or creating one yourself and report your success to devel(a)ovirt.org.
We'll be happy to upload the images once these are ready.
Do you like Debian and do you have some programming skill?
Help us getting VDSM running on it! Debian Jessie has been released a couple of weeks ago and it's a good time for giving it a try.
You can follow the progress here: http://www.ovirt.org/VDSM_on_Debian
Here are some bugs you can hopefully fix in less that one day or you can just try to reproduce providing info:
Bug ID Status Whiteboard Summary
1065350 POST integration hosted-engine should prompt a question at the user when the host was already a host in the engine
1059952 NEW integration hosted-engine --deploy (additional host) will fail if the engine is not using the default self-signed CA
1083104 ASSIGNED integration engine-setup --offline does not update versionlock
1221176 NEW integration hosted-engine accepts FQDNs with underscore while the engine correctly fails on that
1200948 NEW integration hosted-engine-setup should validate the network interface name
Do you want something easier?
Bug ID Whiteboard Status Summary
1174285 i18n NEW [de-DE] "Live Snapshot Support" reads "Live Snapsnot Support"
772931 infra NEW [RFE] Reports should include the name of the oVirt engine
1143817 integration NEW [TEXT ONLY] - Hosted Engine - Instructions for FQDN are not clear enough
1156060 integration NEW [text] engine admin password prompt consistency
1115059 network NEW Incomplete error message when adding VNIC profile to running VM
734120 storage NEW [RFE] VDSM: use virt-sparsify/zerofree to reduce image size
Do you love "DevOps?", you count stable builds in jenkins ci while trying to fall a sleep?
Then oVirt infra team is looking for you!, join the infra team and dive in to do the newest and coolest devops tools today!
Here are some of our open tasks you can help with: https://ovirt-jira.atlassian.net/secure/RapidBoard.jspa?rapidView=1&proje...
You don't have programming skills, not enough time for DevOps but you want still to contribute?
Here are some bugs you can take care of, also without writing a line of code:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20whi...
Do you prefer to test things? We have some test cases[5] you can try using nightly snapshots[6].
You may also help testing: Bug 1234257 - Test upgrade path from EL6 with oVirt 3.5.z to EL7
Do you want to contribute test cases? Most of the features[7] included in oVirt are missing a test case, you're welcome to contribute one!
Is this the first time you try to contribute to oVirt project?
You can start from here [1][2]!
You don't know gerrit very well? You can find some more docs here [3].
Any other question about development? Feel free to ask on devel(a)ovirt.org or on irc channel[4].
You don't really have time / skills for any development / documentation / testing related task?
Spread the word[8]!
Let us know you're getting involved, present yourself and tell us what you're going to do, you'll be welcome!
[1] http://www.ovirt.org/Develop
[2] http://www.ovirt.org/Working_with_oVirt_Gerrit
[3] https://gerrit-review.googlesource.com/Documentation
[4] http://www.ovirt.org/Community
[5] http://www.ovirt.org/Category:TestCase
[6] http://www.ovirt.org/Install_nightly_snapshot
[7] http://www.ovirt.org/Category:Feature
[8] http://www.zdnet.com/article/how-much-longer-can-red-hats-ovirt-remain-co...
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
7 years, 11 months
Reminder: Fedora 20 end of life on 2015-06-23
by Sandro Bonazzola
Hi,
just a reminder that Fedora 20 end of life tomorrow[1].
We're still building rpms targeted to Fedora 20 and we still have servers running on Fedora 20 which won't receive security updates anymore.
Infra please consider to upgrade / re-provision servers / slaves this week.
Since oVirt 3.5 supports Fedora only up to Fedora 20 I think we'll have to continue building packages for it until 3.6 will be out.
For 3.6 I suggest to keep Fedora 20 builds until Wildfly support will be in.
[1] https://lists.fedoraproject.org/pipermail/announce/2015-May/003267.html
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
7 years, 11 months
Live export/import
by Christopher Pereira
Hi,
I would like to migrate a VM between two different ovirt installations with minimum down time.
Using a export domain is slow (requires copying twice) and requires to stop the VM.
It seems like the best option is to 1) create a snapshot, 2) transfer the backing chain images and OVF files to the destination storage domain 3) stop the VM, 4) transfer the active snapshot and 5) import the VM from the destination storage domain.
Can you please comment and suggest other alternatives?
Thanks.
7 years, 11 months
Re: [ovirt-devel] Live export/import
by Christopher Pereira
I attached a copy of a gluster data storage domain (containing VM images and OVF files) to another 3.6 alpha ovirt installation, but the "Virtual Machines" and "Templates" tabs are empty.
Any hint for debugging or known issues?
Christopher Pereira <kripper(a)imatronix.cl> wrote:
>Hi,
>
>I would like to migrate a VM between two different ovirt installations with minimum down time.
>
>Using a export domain is slow (requires copying twice) and requires to stop the VM.
>
>It seems like the best option is to 1) create a snapshot, 2) transfer the backing chain images and OVF files to the destination storage domain 3) stop the VM, 4) transfer the active snapshot and 5) import the VM from the destination storage domain.
>
>Can you please comment and suggest other alternatives?
>
>Thanks.
>
7 years, 11 months
Re: [ovirt-devel] [VDSM] Live snapshot with ceph disks
by Christopher Pereira
Hi Nir,
Regarding "3. Engine creates snapshot *via cinder*"...
What are the benefits of creating snapshots via cinder vs via libvirt?
Libvirt and qemu are offering core VM-aware storage and memory snapshot features.
Besides, snapshot-create-as has no VM downtime.
It would be a mistake to implement snapshoting on the ceph layer.
At some point, you would need VM-aware code (eg: the VM memory state) and organically go back to the libvirt + qemu way.
There seems to be qemu + libvirt support for ceph snapshots (via rbd commands) which probably offers some (?) VM-awareness, but what are the benefits of not using the good old core libvirt + qemu snapshot features?
I must be missing something...
2) Not related:
It seems like oVirt shifted focus towards Ceph recently...
I would like to drop Gluster for Ceph if the latter supports SEEK HOLE reading and optimal sparse files operations. Can someone please confirm if Ceph is supporting SEEK_HOLE? I saw some related code, but would like to ask for comments before setting up and benchmarking Ceph sparse image file operations.
7 years, 11 months
Re: [ovirt-devel] Libvirt secrets management - take 2
by Oved Ourfali
On Jun 12, 2015 14:21, Nir Soffer <nsoffer(a)redhat.com> wrote:
>
> Hi all,
>
> Recently support for Ceph network disk landed in master. It its possible
> now to start a vm using Ceph network disk or hot-plug/unplug such disk
> using Cephx authentication.
>
> However, to make it work, you must add the relevant Ceph secret to
> libvirt manually, in the same way it is done in OpenStack deployment.
> Our goal is to manage secrets automatically and use ephemeral (safer)
> secrets.
>
> The next patches in the Ceph topic [1], implement secret management in
> the same way we manage storage domains or server connections:
>
> The concept is - all hosts can use all secrets, so you can migrate a vm
> using Ceph disk to any host in the cluster.
>
> 1. When host becomes up, we register the secrets associated with all the
> current active domains with libvirt
>
> 2. When activating a domain, we register the secrets associated with the
> new domain with libvirt
>
> 3. When deactivating a domain, we unregister the secrets associated with
> the domain from libvirt
>
> 4. When moving host to maintenance, we clear all secrets
>
> 5. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep
> stale or unneeded secrets on a host
>
> This system seems to work, but Federico pointed few issues and suggested
> a new (simpler?) approach.
>
> In future libvirt version, libvirt will support the concept of transient
> secrets so you can start a transient vm using secret without registering
> the secret with libvirt before starting the vm. The secret will be
> specified in the vm XML (for starting a vm) or disk XML (for hot-plug).
> This will make our secret management system and APIs useless.
When is this planned to be added to libvirt? iiuc, once added, you will no longer need to register the secrets with libvirt, right?
>
> Managing state on multiple hosts is hard; we will probably have to deal
> with nasty edge cases (e.g. lost messages, network errors), which may
> lead to host with missing secret, which cannot run some vms. We probably
> do this right for storage domains (after 8 years?), and we should not
> assume that we are smarter and secret management will work in the first
> try.
>
> The new approach is to *not* manage state or multiple hosts. Instead,
> send the required secrets only to the host that starting a vm or
> hot-plugging a disk that need a libvirt secret:
>
> 1. When starting a vm, add the required secrets to the vm description.
> On the host, vdsm will register these secrets with libvirt before
> starting the vm.
>
> 2. When migrating a vm, add the required secrets to the vm description.
> On the host, vdsm will send these secrets to the destination host,
> and on the destination host, vdsm will register the secrets with libvirt
> before starting the vm.
>
Will these secrets be part of the domain xml?
If so, no need for special treatment in case of VM migration.
> 3. When hot-plugging a disk, send the secret if needed in the disk
> description. On the host, vdsm will register the secrets with libvirt.
>
> 4. When vdsm shutdown or starts, clear all secrets to ensure that we don't keep
> stale or unneeded secrets on a host
>
> 5. We never unregister secrets, since they are ephemeral anyway.
>
> 6. Alternatively, we can implement secrets reference counting so when a vm
> stops or disk is hot-unplugged we decrease the reference count on the
> secrets associated with this vm/disk, and if no other vms need the
> secret, we can unregister the secret from libvirt.
Doesn't seem necessary to me.
>
> The new approach is simpler, if we avoid the fancy secret reference
> counting. I believe we can get it merged in couple of weeks with help
> from the virt team.
>
> Please share your thoughts on these alternative solutions.
>
Keep in mind also hosted engine. Sounds to me like the new approach will be a better fit for it, as he won't need to deal with storage domain secrets, but just pass it in the VM description... Although I'm not a hosted engine expert, so not sure it makes a difference, but it sounds simpler in that aspect as well.
> Thanks,
> Nir
>
> [1] https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic...
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
7 years, 11 months
