<div dir="ltr">Greetings - <div><br></div><div>Upgrade report - all good so far - I'm happy to report that:</div><div><br></div><div>After the first node was upgraded to OVZ7-3515, VEs successfully migrated from the old beta host to the new host <br><div>Both nodes are now up and running on Openvz-3515 and all is well.</div><div><br></div><div>One additional comment: All but one of the VEs live migrated - one had to be dead migrated. This particular VE had ballooned to a size of 48 GB over the months.</div><div><br></div><div>After dead migrating this container and restarting it on the other side, I found and removed a bunch of core files. At this point it needed to be compacted, and the documentation seemed to indicate that there was a vzctl compact option, but it did not in fact seem to exist. The ploop balloon discard operation worked perfectly however, reducing the size from about 48 GB to about 2.7 GB.<br><br>After the compaction, this VE was of course able to live migrate successfully - at the original size, it was obviously hitting some space or time limitation. I'd be curious to know what the exact size limit is.<br><br>All in all, this is a compelling release, which IMHO still has much to recommend it over lxc/lxd<br><br>Jake</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 3:02 PM, jjs - mainphrame <span dir="ltr"><<a href="mailto:jjs@mainphrame.com" target="_blank">jjs@mainphrame.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings,<div><br></div><div>I'm happy to report that a newer release, openvz-3515, allows me to successfully choose a partition type other than the default, and installation is proceeding on node 1.<br><br>Will update with any relevant unexpected findings.<br><br>Jake</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 6:00 PM, jjs - mainphrame <span dir="ltr"><<a href="mailto:jjs@mainphrame.com" target="_blank">jjs@mainphrame.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Chris,<div><br></div><div>Thanks for the feedback - I've had no problem using the anaconda installer on centos, for instance when I set up these existing boxes with OVZ 7 pre-release.</div><div><br></div><div>So I think the installer may not be working as it should. When I change the storage settings and then click on "update" they revert to the original parameters.</div><div><br></div><div>Jake</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 1:55 PM, Chris James <span dir="ltr"><<a href="mailto:cjames@wiredtree.com" target="_blank">cjames@wiredtree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hey Jake,<br>
<br>
It's possible but the disk partitioning interface is buggy. I'm not
sure if you're familiar with the anaconda installer but after you
change a partition from LVM to standard you need to press the
'Update settings' (or something) button in the lower right. The
'/vz' partition will also say it has to be on 'ext4 for vz' but if
you select that it complains about it so you have to select 'ext4'
and then it will auto change it to 'ext4 for vz' and not complain. <br>
<br>
Thanks,<br>
Chris<div><div><br>
<br>
<div>On 07/28/2016 03:32 PM, jjs -
mainphrame wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div dir="ltr">Greetings,
<div><br>
</div>
<div>I decided to give the official openvz 7.0 iso a try and see
how it works. I migrated all containers another host and
prepared to boot from the OVZ 7.0 iso.</div>
<div><br>
</div>
<div>I booted in uefi mode, and the installer crashed with an
error.</div>
<div><br>
</div>
<div>So then, I booted in legacy mode, and the install
proceeded. However, I found that I could not change any of the
partitioning suggestions. For instance, I wanted straight
ext4 partitions, not wanting to bother with LVM, but every
time I modified the storage parameters to try to impose my
will, the parameters were automatically forced back to the
initial suggestions. I decided to postpone the experiment,
since things were not according to expectations. </div>
<div><br>
So I am throwing out this question: Is the inability to choose
plain ext4 partitions a bug, or a feature?<br>
<br>
Jake<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jul 25, 2016 at 12:40 PM,
Sergey Bronnikov <span dir="ltr"><<a href="mailto:sergeyb@openvz.org" target="_blank"></a><a href="mailto:sergeyb@openvz.org" target="_blank">sergeyb@openvz.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m
pleased to announce the release of OpenVZ 7.0. The new
release focuses on<br>
merging OpenVZ and Virtuozzo source codebase, replacing our
own hypervisor with<br>
KVM.<br>
<br>
Key changes in comparison to the last stable OpenVZ release:<br>
<br>
* OpenVZ 7.0 becomes a complete Linux distribution based on
our own VzLinux.<br>
<br>
* The main difference between the Virtuozzo (commercial) and
OpenVZ (free)<br>
versions are the EULA, packages with paid features, and
Anaconda installer.<br>
<br>
* The user documentation is publicly available [1].<br>
<br>
* EZ templates can be used instead of tarballs with template
caches.<br>
<br>
* Additional features (see below)<br>
<br>
<br>
This OpenVZ 7.0 release provides the following major
improvements:<br>
<br>
* RHEL7 (3.10+) kernel.<br>
<br>
* KVM/QEMU hypervisor.<br>
<br>
* Guest tools for virtual machines that currently allow the
following: to<br>
execute commands in VMs from the host, to set user
passwords, to set and obtain<br>
network settings, to change SIDs, to enter VMs.<br>
<br>
* Unified management of containers and KVM virtual machines
with the prlctl tool<br>
and SDK. You get a single universal toolset for all your
CT/VM management needs.<br>
<br>
* UUIDs are used to identify both virtual machines and
containers. With<br>
containers, prlctl treats the former VEID parameter as name.<br>
<br>
* Virtual machine HDD images are stored in the QCOW2 format.<br>
<br>
* Ability to manage containers and VMs with libvirt and
virt-manager or virsh<br>
via a single driver for containers and virtual machines.
Libvirt is an<br>
open-source API, daemon, and management tool for managing
virtualization<br>
platforms. The API is widely used in the orchestration layer
of hypervisors for<br>
cloud-based solutions. OpenVZ considers libvirt as the
standard API for managing<br>
both virtual machines and containers. Libvirt provides
storage management on the<br>
physical host through storage pools and volumes which can be
used in OpenVZ<br>
containers.<br>
<br>
* Memory guarantees. A memory guarantee is a percentage of
container's or<br>
virtual machine's RAM that said container or VM is
guaranteed to have.<br>
<br>
* Memory hotplugging for containers and VMs that allows both
increasing and<br>
reducing CT/VM memory size on the fly, without the need to
reboot. Your<br>
customers can now scale their workloads without any
downtime. This feature also<br>
enables you to make PAYG offerings, allowing customers to
change VM resources<br>
depending on workload and potentially pay less.<br>
<br>
* Kernel same-page merging. To optimize memory usage by
virtual machines, OpenVZ<br>
uses a Linux feature called Kernel Same-Page Merging (KSM).
The KSM daemon ksmd<br>
periodically scans memory for pages with identical content
and merges those into<br>
a single page.<br>
<br>
* VCMMD, the fourth-generation unified memory manager, and
vcmmd, a single<br>
daemon for managing memory of both virtual machines and
containers. OpenVZ 7<br>
uses memcg. Balancing and configuring memcg limits enables
getting the exact<br>
OpenVZ parameters like overcommit, shadow gangs, swap, page
cache overuse.<br>
<br>
* Container live migration via CRIU and P.Haul. In the
previous versions of<br>
OpenVZ, most operations performed during migration were done
in the kernel<br>
space. As a result, the migration process imposed a lot of
restrictions. To<br>
improve upon migration, Virtuozzo launched the CRIU project
aiming to move most<br>
of the migration code to the user space, make the migration
process reliable,<br>
and remove excessive restrictions.<br>
<br>
* Containers use cgroups and namespaces that limit, account
for, and isolate<br>
resource usage as isolated namespaces of a collection of
processes. The<br>
beancounters interface remains in place for backward
compatibility and, at the<br>
same time, acts as a proxy for actual cgroups and namespaces
implementation.<br>
<br>
* SimFS remains in OpenVZ 7.0, however, the support is
limited and we don't have<br>
plans to improve it in future.<br>
<br>
<br>
Known Issues<br>
============<br>
<br>
* OpenVZ 7 includes vzctl from the commercial version. This
means there is no<br>
backward compatibility for the previous version of vzctl
from OpenVZ.<br>
<br>
* vzctl will be obsoleted in next version of OpenVZ,
consider switching to<br>
prlctl or virsh.<br>
<br>
* The full list of known issues and limitations is provided
in the documentation [1].<br>
<br>
<br>
Download<br>
========<br>
<br>
All binary components as well as installation ISO images are
freely available at<br>
the OpenVZ download server [2] and mirrors [3]. The source
code of each<br>
component is available in the public repository [4].<br>
<br>
<br>
FAQ<br>
===<br>
<br>
Q: Can we use the binaries of OpenVZ/Virtuozzo 7.0
distribution in production?<br>
A: Yes.<br>
<br>
Q: Is it possible to upgrade OpenVZ based on 2.6.32/2.6.18
to the OpenVZ/Virtuozzo 7?<br>
A: Yes! Please follow the instructions in the OpenVZ 7
Upgrade Guide [1].<br>
<br>
<br>
Feedback<br>
========<br>
<br>
Our switching to the open development process is an attempt
to work more closely<br>
with the OpenVZ community. You can help us by sending your
feedback to the<br>
users@ mail list or submitting a bug in case of a serious
issue [5].<br>
<br>
Links<br>
=====<br>
<br>
[1] <a href="https://docs.openvz.org/" rel="noreferrer" target="_blank">https://docs.openvz.org/</a><br>
[2] <a href="https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/" rel="noreferrer" target="_blank">https://download.openvz.org/vi<wbr>rtuozzo/releases/7.0/x86_64/is<wbr>o/</a><br>
[3] <a href="https://mirrors.openvz.org/" rel="noreferrer" target="_blank">https://mirrors.openvz.org/</a><br>
[4] <a href="https://src.openvz.org/projects/OVZ" rel="noreferrer" target="_blank">https://src.openvz.org/project<wbr>s/OVZ</a><br>
[5] <a href="https://bugs.openvz.org/" rel="noreferrer" target="_blank">https://bugs.openvz.org/</a><br>
<br>
<br>
Sincerely,<br>
Sergey<br>
______________________________<wbr>_________________<br>
Announce mailing list<br>
<a href="mailto:Announce@openvz.org" target="_blank">Announce@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/announce" rel="noreferrer" target="_blank">https://lists.openvz.org/mailm<wbr>an/listinfo/announce</a></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
Users mailing list
<a href="mailto:Users@openvz.org" target="_blank">Users@openvz.org</a>
<a href="https://lists.openvz.org/mailman/listinfo/users" target="_blank">https://lists.openvz.org/mailm<wbr>an/listinfo/users</a>
</pre>
</blockquote>
<br>
</div>
<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@openvz.org" target="_blank">Users@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.openvz.org/mailm<wbr>an/listinfo/users</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>