Greetings, 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.
Will update with any relevant unexpected findings. Jake On Thu, Jul 28, 2016 at 6:00 PM, jjs - mainphrame <j...@mainphrame.com> wrote: > Hi Chris, > > 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. > > 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. > > Jake > > On Thu, Jul 28, 2016 at 1:55 PM, Chris James <cja...@wiredtree.com> wrote: > >> Hey Jake, >> >> 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. >> >> Thanks, >> Chris >> >> >> On 07/28/2016 03:32 PM, jjs - mainphrame wrote: >> >> Greetings, >> >> 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. >> >> I booted in uefi mode, and the installer crashed with an error. >> >> 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. >> >> So I am throwing out this question: Is the inability to choose plain ext4 >> partitions a bug, or a feature? >> >> Jake >> >> >> On Mon, Jul 25, 2016 at 12:40 PM, Sergey Bronnikov < <serg...@openvz.org> >> serg...@openvz.org> wrote: >> >>> I’m pleased to announce the release of OpenVZ 7.0. The new release >>> focuses on >>> merging OpenVZ and Virtuozzo source codebase, replacing our own >>> hypervisor with >>> KVM. >>> >>> Key changes in comparison to the last stable OpenVZ release: >>> >>> * OpenVZ 7.0 becomes a complete Linux distribution based on our own >>> VzLinux. >>> >>> * The main difference between the Virtuozzo (commercial) and OpenVZ >>> (free) >>> versions are the EULA, packages with paid features, and Anaconda >>> installer. >>> >>> * The user documentation is publicly available [1]. >>> >>> * EZ templates can be used instead of tarballs with template caches. >>> >>> * Additional features (see below) >>> >>> >>> This OpenVZ 7.0 release provides the following major improvements: >>> >>> * RHEL7 (3.10+) kernel. >>> >>> * KVM/QEMU hypervisor. >>> >>> * Guest tools for virtual machines that currently allow the following: to >>> execute commands in VMs from the host, to set user passwords, to set and >>> obtain >>> network settings, to change SIDs, to enter VMs. >>> >>> * Unified management of containers and KVM virtual machines with the >>> prlctl tool >>> and SDK. You get a single universal toolset for all your CT/VM >>> management needs. >>> >>> * UUIDs are used to identify both virtual machines and containers. With >>> containers, prlctl treats the former VEID parameter as name. >>> >>> * Virtual machine HDD images are stored in the QCOW2 format. >>> >>> * Ability to manage containers and VMs with libvirt and virt-manager or >>> virsh >>> via a single driver for containers and virtual machines. Libvirt is an >>> open-source API, daemon, and management tool for managing virtualization >>> platforms. The API is widely used in the orchestration layer of >>> hypervisors for >>> cloud-based solutions. OpenVZ considers libvirt as the standard API for >>> managing >>> both virtual machines and containers. Libvirt provides storage >>> management on the >>> physical host through storage pools and volumes which can be used in >>> OpenVZ >>> containers. >>> >>> * Memory guarantees. A memory guarantee is a percentage of container's or >>> virtual machine's RAM that said container or VM is guaranteed to have. >>> >>> * Memory hotplugging for containers and VMs that allows both increasing >>> and >>> reducing CT/VM memory size on the fly, without the need to reboot. Your >>> customers can now scale their workloads without any downtime. This >>> feature also >>> enables you to make PAYG offerings, allowing customers to change VM >>> resources >>> depending on workload and potentially pay less. >>> >>> * Kernel same-page merging. To optimize memory usage by virtual >>> machines, OpenVZ >>> uses a Linux feature called Kernel Same-Page Merging (KSM). The KSM >>> daemon ksmd >>> periodically scans memory for pages with identical content and merges >>> those into >>> a single page. >>> >>> * VCMMD, the fourth-generation unified memory manager, and vcmmd, a >>> single >>> daemon for managing memory of both virtual machines and containers. >>> OpenVZ 7 >>> uses memcg. Balancing and configuring memcg limits enables getting the >>> exact >>> OpenVZ parameters like overcommit, shadow gangs, swap, page cache >>> overuse. >>> >>> * Container live migration via CRIU and P.Haul. In the previous versions >>> of >>> OpenVZ, most operations performed during migration were done in the >>> kernel >>> space. As a result, the migration process imposed a lot of restrictions. >>> To >>> improve upon migration, Virtuozzo launched the CRIU project aiming to >>> move most >>> of the migration code to the user space, make the migration process >>> reliable, >>> and remove excessive restrictions. >>> >>> * Containers use cgroups and namespaces that limit, account for, and >>> isolate >>> resource usage as isolated namespaces of a collection of processes. The >>> beancounters interface remains in place for backward compatibility and, >>> at the >>> same time, acts as a proxy for actual cgroups and namespaces >>> implementation. >>> >>> * SimFS remains in OpenVZ 7.0, however, the support is limited and we >>> don't have >>> plans to improve it in future. >>> >>> >>> Known Issues >>> ============ >>> >>> * OpenVZ 7 includes vzctl from the commercial version. This means there >>> is no >>> backward compatibility for the previous version of vzctl from OpenVZ. >>> >>> * vzctl will be obsoleted in next version of OpenVZ, consider switching >>> to >>> prlctl or virsh. >>> >>> * The full list of known issues and limitations is provided in the >>> documentation [1]. >>> >>> >>> Download >>> ======== >>> >>> All binary components as well as installation ISO images are freely >>> available at >>> the OpenVZ download server [2] and mirrors [3]. The source code of each >>> component is available in the public repository [4]. >>> >>> >>> FAQ >>> === >>> >>> Q: Can we use the binaries of OpenVZ/Virtuozzo 7.0 distribution in >>> production? >>> A: Yes. >>> >>> Q: Is it possible to upgrade OpenVZ based on 2.6.32/2.6.18 to the >>> OpenVZ/Virtuozzo 7? >>> A: Yes! Please follow the instructions in the OpenVZ 7 Upgrade Guide [1]. >>> >>> >>> Feedback >>> ======== >>> >>> Our switching to the open development process is an attempt to work more >>> closely >>> with the OpenVZ community. You can help us by sending your feedback to >>> the >>> users@ mail list or submitting a bug in case of a serious issue [5]. >>> >>> Links >>> ===== >>> >>> [1] https://docs.openvz.org/ >>> [2] https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/ >>> [3] https://mirrors.openvz.org/ >>> [4] https://src.openvz.org/projects/OVZ >>> [5] https://bugs.openvz.org/ >>> >>> >>> Sincerely, >>> Sergey >>> _______________________________________________ >>> Announce mailing list >>> annou...@openvz.org >>> https://lists.openvz.org/mailman/listinfo/announce >> >> >> >> >> _______________________________________________ >> Users mailing >> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users@openvz.org >> https://lists.openvz.org/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users