-
某局点云桌面_批量添加AD域用户问题
问题描述 在windows server 2008系统中无法通过csvde来批量添加域用户。 告警信息 批量创建AD域用户失败。 处理过程 1.在百度等各大搜索平台以及华为论坛都没有找到相关的批量添加AD域用户的命令，这会导致如果有上千个域用户需要添加，那么就需要手动去添加这上千个用户名，工作量太大。 2.向400工程师以及办事处寻求帮助，但是都没有相关的经验，没能提出解决方法。 3.考虑上微软官网找相关的命令格式，最终找到了，命令如“dsadd user cn=gwy001,OU=GongwuyuanjuOU,DC=vdesktop,DC=huawei,DC=com -pwd Huawei@123 -pwdneverexpires yes”，解释一下，－pwdneverexpires yes这一段是设置密码为永不过期的意思，那么可以按照此命令格式编成一个文本文档，然后一次性粘贴到AD域的命令行里执行，这样就可以将所有的域用户一次性批量生成。 4.生成之后，还需要做一个手工的操作，因为命令成功后，查看用户属性，你会发现“用户登录名”处为空白，这会导致虚拟机无法自动登录， 这里目前我还没有研究出如何批量添加用户UPN，只能通过手工去添加用户UPN。 根因 csvde批量添加域用户的方式不适合windwos server 2008 R2系统，在系统命令行中执行失败。 解决方案 微软官网找相关的命令格式，命令如“dsadd user cn=gwy001,OU=GongwuyuanjuOU,DC=vdesktop,DC=huawei,DC=com -pwd Huawei@123 -pwdneverexpires yes” 建议与总结 综上所述，关于dsadd命令批量添加AD域用户，总结以下几点： 1.dsadd命令方式只能把所有的脚本复制在系统命令行里执行，不能编辑成表格类的类型然后使用命令去执行它。 2.dsadd批量添加域用户后，需要手工去添加用户UPN。 3.dsadd批量添加域用户方式只适合500以内数量的用户添加，数量太大的话，手工添加用户UPN的工作量也很大。 所以希望有相关经验的工程师能把更好的批量添加域用户的方……
SE_You
2024-08-06
18 0 0 -
Windows CIFS共享到Linux拷贝速度慢
问题描述 某局点客户反映数据从Linux虚拟机拷贝到Windows虚拟机速度正常，但是从Windows拷贝到Linux速度缓慢。 客户在FusionCompute里Windows虚拟机创建CIFS共享文件挂载到Linux虚拟机，从linux到CIFS共享文件数据拷贝速度正常，反方向从CIFS共享文件到Linux数据拷贝缓慢。 处理过程 1、 在客户现场搭建虚拟机测试环境，一台WindServer2008创建CIFS共享文件，一台Linux （CentOS），CIFS共享文件挂载到Linux，测试发现数据从Linux虚拟机拷贝到Windows虚拟机速度正常有80MB/s，但是从Windows拷贝到Linux速度在20MB/s，速度慢。经分析FusionCompute与外界物理环境正常，怀疑和CIFS协议本身相关 2、 在Windows搭建FTP环境，Linux进行FTP拷贝速度40+MB/s（三次测试FTP拷贝速度最低58MB/s） 3、 研发在家里测试CIFS共享方式在windows于linux系统之间数据拷贝，测试结果linux到windows拷贝速度106MB/s，windows到linux拷贝速度25MB/s，研发家里环境测试结果与现场测试结果相同，证明该问题由CIFS本身协议限制导致速度拷贝慢。 根因 Linux虚拟机拷贝到Windows慢的问题由使用协议本身限制，导致拷贝速度慢（CIFS协议与Linux的direct写冲突，只能通过undirect的方式进行拷贝操作，而undirect方式本身使用缓存会导致拷贝速度不准确） 建议与总结 1.Windows到linux的数据拷贝不建议用CIFS共享方式，该方式传输速度比较慢，一般常见FTP方式能正常较快的传输数据。 2．N8000的CIFS共享在Linux下的数据拷贝不在该问题处理的测试范围，文档中的终结对N8000无参考价值。
SE_You
2024-08-05
71 0 0 -
Linux系统挂载数据盘导致数据丢失的解决方法
问题描述 1、用户系统为Linux系统，用户自己挂载新的文件系统在/opt目录下，发现原始/opt目录下数据丢失。 2、登录虚拟机，执行如下命令： # cd /opt/ # ls 发现/opt目录下没有数据 告警信息 该故障无伴随告警产生。 处理过程 1、登录虚拟机，执行如下命令： #umount /opt #cd /opt/ #ls 用户之前的数据存放在vi.recover文档下 2、执行命令： #mv ./* /mnt #mount /dev/xvde1 /opt 根因 1、咨询过用户，没有删除操作 2、用户挂载新的数据盘到/opt目录，改目录下已存在原始数据盘 3、分析为用户虚拟机/opt下已经挂载了数据盘，新的数据盘覆盖了原始数据盘 解决方案 1、挂盘前检查/opt目录下是否已经挂在数据盘 2、先把原始数据盘数据拷贝出来，解挂原始数据盘 3、把新数据盘挂载上去，把从原始数据盘拷贝出的数据拷贝上去 建议与总结 无
SE_You
2024-08-02
317 0 0 -
FusionComputer 中制作 suse系统的模板时进入repair filesystem模式的解决方法
问题描述 制作suse系统的模板，只保留系统盘，卸载数据盘后开机后系统进入repair filesystem模式的情况，如图： 告警信息 该故障无伴随告警产生。 处理过程 1、 根据第一种情况输入以下命令： (repair filesystem) # fsck /dev/vxdax （或执行fsck命令，执行完后重启系统） (repair filesystem)#fsck （修复过程中会遇到等待确认的情况，直接按y+回车键即可）然后重启系统，重启后系统后依旧进入repair filesystem模式，说明不是非正常关机或者强制重启造成系统进入repair filesystem模式的。 2、 如果导致suse进入修复模式的原因是第二种情况，解决方法就是修改/etc/fstab文件，删除错误的或者是不存在的挂载目录,，将配置恢复正常。 （修复模式下（read-only system） 文件是被保护的不能修改，运行下面命令,把系统文件权限改成可读写（rw）, 使根目录可写．即可以修复/etc/fstab文件，使之可写．然后就可以vi修改了,保存 wq，最后重启虚拟机） repair filesystem # vi /etc/fstab repair filesystem # mount -o remount,rw / repair filesystem #reboot 本例属于第二种情况，挂载的数据盘已经卸载，可是在挂载目录里的挂载路径还在导致系统进入repair filesystem模式，下图红线标注的挂载目录信息删除系统即可恢复正常 根因 Suse系统进入repair filesystem模式有两种情况： 1、 第一种情况：可能非正常关机引起的磁盘分区问题（如：在FC里面强制重启VM），不能正常进入系统 2、 第二种情况：由于/etc/fstab文件编辑错误而导致的不能正常进入系统 建议与总结 无
SE_You
2024-08-01
28 0 0 -
FusionCompute_win2003虚拟机无法重定向U盘
问题描述 FusionCompute_win2003的虚拟机发放完毕后无法重定向U盘，造成USB无法使用。 告警信息 无 处理过程 1、 下载windows2003USB路径程序包并在win2003的操作系统里面安装，下载地址http://support.microsoft.com/kb/944704。 2、 在FusionCompute上，打开虚拟机和模板，虚拟机，查看该虚拟机所在哪个服务器节点。 3、 然后把U盘插在该节点USB口。选中虚拟机---硬件，选中USB设备，点击“绑定USB设备”。 4、正常将会在下方显示你插入的U盘型号，所属主机等信息。选中它后，选择主机。点击确定。 5、 进入windows2003虚拟机。就可以看到U盘了。 根因 无
SE_You
2024-07-31
7 0 0 -
数据存储空间不足导致虚拟机删除快照失败
问题描述 2014年8月18日上午9:15左右接某局点上报虚拟机无法登录问题，虚拟机于8月17日凌晨1:10左右使用HyperDP做虚拟机备份，创建快照成功，但是删除快照时，截止到8月18号上午10:00，任务一直进行中。FC Portal上无法重启VM，提示有任务在进行 告警信息 FC Portal上有告警如下图： 处理过程 1、 登录VRM数据库查看快照删除任务的详细状态发现：虚拟机系统盘快照已经删除成功，数据盘快照一直处于删除中的状态 2、 为了尽快恢复客户业务，从底层对该虚拟机执行下电操作，虚拟机下电成功，再给系统进行上电，系统卡在启动页面，无法正常进入系统。登录虚拟机所在的CNA节点，虚拟机数据盘所在的数据存储HW_Cloud_P_lun01已经达到100%，实际可用空间变为0 3、 进一步分析问题触发因素：数据存储空间占用率过高→虚拟机创建快照→数据存储可用空间为0→虚拟机删除快照任务卡住→虚拟机无法重启、虚拟机故障、业务异常 4、问题出现的根因就是数据存储实际可用空间为0，导致虚拟机业务异常，因此需要迁移该数据存储中的部分磁盘至其他有可用容量的数据存储上去，然后执行快照删除动作，重新启动虚拟机 根因 数据存储空间被占满导致快照无法删除，从而影响虚拟机业务。 建议与总结 数据存储使用率已经接近或者达到100%，虚拟机在删除快照时，无法申请到可用空间，快照删除任务卡死。虚拟机手动关闭重新上电后，同样是因为数据存储使用率已经达到100%，导致无法正常读写数据，虚拟机启动异常。建议在存储空间使用上，要留有一定的余量，尽量在告警阀值一下，尤其是部署HDP的场景。
SE_You
2024-07-30
22 0 0 -
Win2003 虚拟机vnc登录花屏
问题描述 某局点反馈多次通过mstsc远程登录win2003虚拟机且不及时注销退出，而是通过直接点击右上角的关闭按钮退出。一段时间后，因mstsc远程登录连接数满导致虚拟机无法远程登陆。客户通过管理平台VNC工具登录虚拟机，发现VNC界面呈现花屏状态且无法执行登录操作。 告警信息 无 处理过程 1、禁用Cirrus显卡，在出现花屏的虚拟机中禁用Cirrus显卡。 具体方法：右键“我的电脑”->管理->设备管理器->显示卡->右键“Cirrus Logical 5446 兼容图形适配卡”，选择“停用”。 此方法，禁用Cirrus显卡以后，仅支持800*600、1024*768和1280*1024三种分辨率调节 2、重启该VM 根因 1、通过FusionCompute集成的VNC工具登录虚拟机，发现VNC界面为花屏状态。首先怀疑是集成的VNC工具问题。通过本地的VNC工具登录虚拟机仍呈现花屏状态，可以排除此因素导致。 2、排除VNC客户端后，怀疑是VNC服务端的问题。通过登录出问题的虚拟机所在的CNA节点，收集相关底层虚拟化日志信息并进行分析，没有发现有异常日志信息。同时观察节点的压力也较轻，没有出现负载超负荷的情况。因此可以基本排除虚拟化层导致该问题。 3、最后怀疑GuestOS内部问题，通过查阅相关的资料，发现在案例库中有类似的相关案例。是win2003虚拟机将分辨率调大之后再调小后会出现花屏。或者长时间不使用导致屏幕锁定后也会有花屏现象出现（详情见附件）。综上分析，怀疑该局点的花屏问题跟cirrus显卡的显存信息相关度较大。建议局点按照以下的规避方案在其中一台多次出现花屏问题的虚拟机上实施并观测2周，如果没有问题就可以确认是同样的根因。 建议与总结 定期重启VM，如果出现花屏，建议禁用禁用Cirrus显卡
SE_You
2024-07-29
23 0 0 -
FusionCompute R3C10版本 PXE安装CNA异常
问题描述 FC 安装完vrm后，使用PXE方式安装加载cna操作系统（2288H V2服务器），讲便携机作为DHCP服务器，配置FTP，TFTP软件以及准备版本自带的PXE包，在所有配置都正确完成的情况下，实施过程中出现所有CNA无法正确的获取TFTP分配的临时IP，通过命令查询，显示requested address not available，手动配置临时IP可以ping通便携机IP（网关）。 告警信息 无法正常获取DHCP的临时IP，通过命令查询回写requested address not available 处理过程 经一系列排查，最终将问题锁定在VRM自身的DHCP功能上。经与版本研发兄弟确认，VRM本身确实自带DHCP功能（分配子网ip），会影响PXE的正常进行。 找出问题根因后，将vrm的eth0口断连，重启其他CNA节点，成功完成PXE安装。 根因 猜想： 1.TFTP文件夹下default文件中的IP与便携机IP不符，导致无法正常获取IP--经检查，配置无误。 2.FTP配置错误--经检查，配置无误。 3.机柜内交换机存在配置，导致网络不通，无法与便携机通信--经查看，交换机无任何配置 4.局域网内存在多个DHCP服务器，导致地址不合法，无法正确分配--经检查，机柜内存在已经安装完OS的VRM，其eth0与其他CNA的eth0口直连同一台交换机，可以互相通信，怀疑VRM自身携带DHCP功能。 建议与总结 在使用PXE方式进行CNA的操作系统安装时，务必注意局域网中有且只能有一台DHCP服务器，同时要谨记我们的VRM自身就可以当做DHCP服务器，在做PXE时，要记得将VRM服务器上用于加载系统的那个业务口断连！
SE_You
2024-07-26
12 0 0 -
FusionCompute R3C00版本VRM定时备份数据库导致VRM系统自动下电
问题描述 FusionCompute R3C00 VRM主节点操作系统自动下电，业务切换到备节点 注：VRM物理部署 告警信息 部件类型: FusionCompute, 告警名称: 主备间节点心跳故障, 告警级别: 紧急, 产生时间: 2014-08-28 02:19:22 UTC+08:00, 告警对象: hghfsc005vrm 处理过程 1、FusionCompute portal出现告警，主备间节点心跳故障； 2、登陆故障VRM所在服务器的BMC portal，发现操作系统下电，如下图所示； 3、通过BMC手工上电服务器恢复； 4、清理不需要的归档日志及安装包 5、升级R3C10版本 根因 分析过程： 1、FusionCompute portal出现告警，主备间节点心跳故障； 2、登陆故障VRM所在服务器的BMC portal，发现操作系统下电，通过BMC日志可查看到下电时间； 3、通过BMC手工上电服务器恢复； 4、通过putty登陆VRM操作系统，查看/var/log/目录下对应时间点的message日志，发现系统自动下电，发送shutting down命令，相关日志信息如下图所示 5、查看/var/log/galaxenginelog/watchdog/目录下查看对应时间点的watchdog日志，发现无磁盘空间，相关信息如下： 6、通过df -h命令查看，操作系统根分区剩余空间为0，查看/tmp/ge_backup目录达到5G左右，该目录为FusionCompute备份数据的临时目录，如下图所示 7、清理/tmp/ge_backup临时目录，释放根分区空间，如下图所示 根因：FusionCompute R3C00版本备份数据库首先把数据放到/tmp/ge_backup目录下，然后再放到/var下生成压缩文件，如果根分区剩余空间小于数据库大小，会导致根分区空间被占满，系统自动下电 建议与总结 1、根据站点实际情况，调整VRM分区大小 2、调整临时目录到其他分区，FusionCompute R3C10版本已经将临时目录调整到/var下
SE_You
2024-07-25
26 0 0 -
FusionCompute关联存储失败
问题描述 使用Windows2012服务器做的磁盘，通过ISCSI方式映射给CNA节点，在FusionCompute界面关联存储时失败，提示“关联存储资源时出错”，如下图： 告警信息 无。 处理过程 将CNA01节点/etc/iscsi/initatorname.iscsi文件中的名称InitiatorName=IQN修改为InitiatorName=iqn.2014-05.com.huawei.10:bf:48:4c:45:f7:65，后并执行/etc/init.d/open-iscsi restart 重启iscsi服务后，重新再关联存储。 根因 查看系统日志显示发现设备失败了，现场两个节点，其中CNA01关联存储失败，CNA02可以正常关联，由于客户手动修改过CNA01的iqn号，查看iscsi 的启动器名称：显示为IQN，与实际在服务器上看到的不一致，导致关联失败，CAN01节点日志报错如下图： 对比两台CAN节点的/etc/iscsi/initatorname.iscsi文件显示如下： CNA01主机显示如下，而正确的应该为InitiatorName=iqn.2014-05.com.huawei.10:bf:48:4c:45:f7:65 CNA02主机： 建议与总结 建议不要随意修改主机的IQN号。
SE_You
2024-07-24
69 0 0
FusionCompute
