直接针对VMware，PVE简直就是虚拟化市场的大杀器，我原来希望通过openstack对VMware的替代，后面才发现PVE才是VMware最好的开源替代产品。
一、单个用户绑定VM1、添加pve用户：2、添加用户权限，与用户虚拟机绑定：二、群组用户；1、创建群组：2、添加几个用户到群组：3、添加组权限，绑定1个虚拟机，这个组的所有用户都可以访问这个虚拟机：三、自定义权限1、创建角色，比如分配虚拟机电源管理、监控、console三个全选给VMuser角色：2、添加权限给群组或者用户，绑定新建的VMuser角色：三、AD域控账号管理：1、添加AD域控管理服务
工作上excel多次用到了多表级联查询功能，类似于sql语句：updatetablesetcol=valuewhere'查询条件'里面的的功能。老是忘记怎么用，记录一下。参考了这个网址：https://www..com/Lamfai/p/9848937.html公式：在C2输入“=VLOOKUP(B2,E1:G4,2,1)”，下拉填充。对我来说，用下面的sql语句比较好理解。upda
几个知识点：use Cwd 引用当前目录cwd：当前目录shift：获取位置参数；chdir 改变目录位置opendir 打开目录closedir 关闭目录foreach 。。。next#!perl -w use strict; use Cwd; // sub scanDirectory { my $workdir=shift; my $startdir=cwd; ch
ZFS最早是oracle推出的一款存储管理系统，它结合了文件系统和卷管理的优点，再加上磁盘管理，不需要先将磁盘划分卷，直接对磁盘进行管理（中间可以设置RAIDZ），实际使用 通过zpool 。感觉使用起来还是很方便，比传统的磁盘和文件系统管理方式要简便，如果对传统的文件系统和磁盘管理方式比较熟悉的话，ZFS还是比较好理解的。 ZFS如果直接通过zfs-fuse来管理，效率会低，因为每
转载自：https://www.getnas.com/open-source-nas/市面上能见到的 NAS 操作系统很多，有如 FreeNAS 这样意气风发的开源免费版，也有完全商业的闭源版本，更有如黑群晖之类的破解版本。NAS 系统的迭代是一个大浪淘沙的过程，活下来的系统在功能上逐渐趋同，这代表了市场的普遍需求。本页旨在汇总开源 NAS 操作系统，为大家 DIY NAS 提供一些参考。Free
常用的ansible命令，备忘。
继上次安装完成oVirt engine之后，需要再安装node节点作为虚拟机的宿主机。本次操作参考官网： https://ovirt.org/documentation/install-guide/chap-oVirt_Nodes.html 安装oVirt node节点有两种方式，一种方式是直接下载一个定制的ISO镜像直接安装，一种方式是先最小化安装rhel redhat7 或者centos7 ，然后在此基础再安装oVirt node安装包，建议采用第一种方式，下载安装镜像： https://resources.ovirt.org/pub/ovirt-4.3/iso/ovirt-node-ng-installer/4.3.6-2019092614/el7/ovirt-node-ng-installer-4.3.6-2019092614.el7.iso 安装过程完全参考官网安装文档。
在研究桌面云的过程中，发现对于真正落地来说，服务端（私有云或者虚拟化）没有太多的区别，更多的是瘦客户端的使用和对桌面的管理方面有诸多需要考虑的地方，最终落地可能都是需要定制化开发才能很好的满足需求。在开源虚拟化产品中，限于自己的经验和眼界，Ovirt原来一直没有接触，在和朋友的沟通过程中，发现Ovirt对于桌面云解决方案更接地气，更具有项目落地的优势。Ovirt官网安装参考：https://ovi
第一个程序是在树莓派上开发一个远程登录界面登录远程桌面，使用freerdp ，命令行方式很简单，就是一条命令： xfreerdp /f /v:192.168.170.21 /u:yuweibing /p:sdfsdf 我要做的就是开发一个登录界面，类似windows中的远程桌面登录界面，让用户自己输入账号密码，然后登录。 下面是简单过程和成果展示：
pycharm 代码上传到服务器，备忘
使用pyqt5进行编程，使用pyhcarm+designer，其中designer直接生成ui文件，通过pyuic5 命令将生成的ui文件转化为py文件rdpgui.py，图形界面py文件只管图形的事情，信号+槽另外一个py文件MainWindow.py，最后一个main.py文件中主函数执行实例化上面这个MainWindow.py ，并调用show() 显示。逻辑关系是这样的： rdpgui.py -> MainWindow.py -> main.py
沿着在树莓派中开发瘦客户端连接远程桌面GUI程序这条主线，摸到了这里，使用pyqt5开发图形界面之后，程序读取一个ini配置文件，将远程连接的相关参数写到这个ini配置文件中。这样可以实现一个最简版的远程桌面连接程序。
在使用pycharm进行编写代码的时候，发现信号设置了connect一个槽，但是测试发现没有起作用，另外，在pycharm编辑器上connect提示没有这个函数，总是找不到原因，后面决定还是对碰到相应的知识点需要做对应的测试用例进行学习和验证。
使用pycharm编写python，编程效率会提高很多，熟练使用快捷键，如虎添翼。
使用pyqt5的时候，使用图形化工具开发图形界面效率会高很多，需要安装designer，记录一下安装过程，备忘。
为了对应开发不同版本的python程序，需要设置不同版本的开发环境。这里做一个简单记录，备忘。
记录一下python开发环境安装
此次V6.0版本有一个逆天的新功能，宿主机本地盘（local disk）上的虚拟机可以实现热迁移！ 今天抽空验证本地磁盘虚拟机实现热迁移。 结论： 1、pve6.0版本能够实现本地磁盘虚拟机热迁移； 2、整个过程没有在pve后端执行一条命令（测试除外）；
聊聊这次RHCE的考试经验，算是对自己花了这么些钱和时间通过这个认证有个交代
如果为了在安装harbor的时候省事采用http的方式部署，使用的时候docker客户端默认使用register仓库的时候都是使用安全连接https，如果要改为http需要修改docker配置，很是麻烦。因此还是需要使用https方式。 从http方式改为https方式主要是需要重新生成CA证书（颁发机构），web服务器证书（harbor服务器），以及服务器向CA进行签发注册。之后修改harbor.cfg配置文件，将服务器证书文件配置到配置文件中，修改hostname从IP地址改为域名，重新prepare和install ，install程序会自己将原来的docker-compose中的容器删除重新生成。 重新安装后的用户信息和镜像数据都会保留。
新的单位使用了cloudstack作为云平台的基础架构，老规矩，通过动手搭建一个实验环境熟悉一下cloudstack的基本的组件。 整个安装过程比预想的还简单，概念清晰，感觉比openstack更友好。虚拟机的使用和管理也要比openstack要方便，存储管理很灵活，网络管理还没来得及测试。总之，整体比openstack要好用，但是好像还没看到相关PAAS层的东西，比如类似openstack的大数据组件sahara、对象存储组件swift、文件系统manila等，也正常，cloudstack官网本身也说是提供IAAS层的。 但如果纯粹作为iaas层虚拟来使用的话，感觉还是不如proxmoxVE好用。对于各个虚拟化的纳管来说，可能相对于proxmoxVE更强一些，比如对于同时有VMWare虚拟化、kvm虚拟化以及xen虚拟机的环境来说，cloudstack可以同时进行纳管，这一块还没有经过实际测试，使用起来不知道是不是方便 。 多一个选择总是好的，都是好东西，看不同的场景，可以有不同的选择。
记录一下直接从pve物理机中（debian9）通过usb口直接拷贝数据到移动硬盘中。 移动硬盘是使用NTFS文件格式，刚开始直接挂载发现提示不能写，只读：root@pve1:~# mount /dev/sdf1 /media/ root@pve1:~# cd&nbs
办公用的瘦客户端使用的是spice协议连接，今天要用移动硬盘（希捷）拷贝一些东西，记录一下配置过程。 使用瘦客户端的USB口需要简单几个步骤就行。首先是在pve管理界面上对虚拟机的硬件设备增加usb 的spice port ，然后将虚拟机关闭（注意，重启不行，一定要关闭）使配置生效。然后在虚拟机中安装Us
这个实验做下来，对我来说主要的难点在于不熟悉版本管理工具marven以及git等开发方面的工具，只能说对CI/CD持续集成部署做了一次简单的摸索。 使用过程中遇到任何问题，首先看报错和日志，问题最多的地方是jenkins的pipeline脚本执行，在执行过程中，需要对脚本有一个充分的消化了解，碰到问题的时候，通过查看输入日志来定位问题所在。 整个结构主要包括3个部分，镜像仓库harbor、jenkins、docker ，其中还有git仓库和git客户端，直接复用放在了harbor服务器上 。harbor是原来部署过的资源，jenkins是直接通过下载war包部署在tomcat上，docker与harbor之间的配置需要匹配，我的环境里面harbor配置的是http方式，需要在docker端配置insecure registry 。 CI/CD持续集成部署对于开发测试来说还是非常有用的，这个实验是使用docker作为容器的运行环境（slave） ，另外，还可以使用kubernetes作为容器承载环境，配置会更复杂一些，但是部署完成后的使用会更加健壮
Harbor的安装使用都是很方便的，部署方式本身也是通过docker和容器编排docker-compose 实现 ，主要解决了局域网内的容器镜像管理问题。 这里没有使用https的方式部署，使用的是http方式，其中需要注意客户端docker中需要配置对“非安全” http的支持，加入--inscure-registry 参数的支持。 Harbor产品本身解决了本地局域网内部集中管理容器镜像的问题，如果是生产环境，可以考虑再加入同步复制的功能以确保数据的安全性，这里就不展开说，我也没用到，用到的时候再说。
原来一直想偷懒直接使用kubernetes的kubeadmin 部署工具自动化部署，但是，由于软件安装源的问题，对相关模块的相互关系都不熟悉，另外，由于工作上面也没有用到，没有足够的热情，这个实验一直没能完成 ，后面订阅了一个订阅号专门介绍kubernetes这一块的内容，还是老老实实跟着老师傅通过二进制包进行安装，这样也可以对k8s的整个体系结构会更加了解。
实验参考文章，转载自： http://blog.51cto.com/lizhenliang/2325770
ProxmoxVE确实使用太方便了，对于稍显复杂的ceph分布式存储，已经做到了方便实施的极限，只需要简单几条初始化的指令，后面全部通过web管理界面进行配置和部署，方便至极，更棒的是，web管理界面还可以实时看到ceph存储的各种状态，相当于完全把ceph存储的管理融合进了PVE的统一管理。 但是使用ceph的前提是，必须对ceph分布式存储本身的一些概念弄清楚，比如ceph 的存储规则，pg的概念，bucket的概念，ceph自身的功能组件mon、osd、pool的概念等等，建议如果对这些概念不熟悉，先通读一遍ceph社区官网的文档，然后动手搭建ceph存储试验。熟悉ceph之后，回过头来再使用pve自带的ceph管理功能就显得非常简单了。 通过上面的实验，也可以看到ProxmoxVE可以做到在自己的平台上快速搭建环境嵌套虚拟化，可以方便广大的PVE爱好者快速的熟悉PVE 的使用。通过我个人的经历，openstack的试验过程和复杂度，比PVE要高出好多倍，openstack如果要做一个完整的试验下来，熟练的情况下，如果要5天，那么，PVE的试验，
继上次在PVE环境上搭建了oracle12C RAC环境（请参考博文“ProxmoxVE 之 安装oracle12C rac集群”）并且安装使用CDB和PDB（请参考博文“ProxmoxVE 之 安装oracle12C 数据库（CDB和PDB）”）之后，继续往下深入，在这个RAC环境中安装第二个CDB，验证一个RAC环境下面使用多个CDB和PDB的复杂应用情况。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
