本发明涉及通信技术领域，具体而言，涉及一种虚拟设备配置方法及网络设备。
背景技术：
虚拟化技术是一种将底层硬件设备与上层操作系统、应用程序进行分离去耦合的技术。虚拟化技术是当前流行的云计算平台的底层重要支撑技术之一，可极大地提高设备的资源使用效率。尤其是在当前的中高端分布式网络设备中，随着网络设备的物理板卡、内存、cpu(centralprocessingunit，中央处理器)、磁盘等资源的不断增加，处理性能的不断提升，可利用虚拟化技术将实体的物理设备虚拟化为多个虚拟设备，以便于将上述资源划分给不同的租户使用，进而提高网络设备的整体利用率。
然而，虚拟设备的稳定性及抗干扰性不如物理设备，虚拟设备在工作过程中容易出现异常，影响正常业务处理。因此，在虚拟设备发生异常时如何保证业务的正常运行是目前虚拟化技术领域中需要解决的主要问题之一。
技术实现要素：
本发明实施例提供一种虚拟设备配置方法及网络设备。
第一方面，本发明实施例提供一种虚拟设备配置方法，所述方法应用于包括至少两个主控卡的网络设备，所述方法包括：
第一主控卡获取用于进行虚拟设备配置的配置命令请求；
所述第一主控卡根据所述配置命令请求进行第一主控卡虚拟设备配置，并在配置完成时将所述配置命令请求发送给第二主控卡；
所述第二主控卡根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡发送配置完成的反馈消息。
在本申请上述第一方面实施例提供的技术方案中，所述第一主控卡可对第二主控卡的配置操作进行管控，以便于在第一主控卡的虚拟设备发生异常时，第二主控卡的虚拟设备可及时接替工作，及时备份。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，在所述第二主控卡根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡发送配置完成的反馈消息的步骤之后，所述方法还包括：
所述第一主控卡向客户端设备发送配置成功的通知消息。
可见，在本发明实施例中，所述第一主控卡只有在确认主、从虚拟设备配置都操作成功后，才会生成并发送配置成功的通知消息给用户。由此，可确保从虚拟设备随时处于准备就绪的状态，以便于当主虚拟设备异常时，从虚拟设备能够及时接替所述主虚拟设备的工作。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述第一主控卡中运行有配置客户端进程及所述网络设备的主虚拟设备管理进程，所述第一主控卡获取用于进行虚拟设备配置的配置命令请求，包括：
所述配置客户端进程通过串口获取用于进行虚拟设备配置的配置命令请求；
所述配置客户端进程对所述配置命令请求进行封装，并将经过封装的配置命令请求发送给所述主虚拟设备管理进程。
可见，在本发明实施例中，由第一主控卡上的配置客户端进程统一负责与客户端设备进行对接，第二主控卡无需关心与客户端设备的对接问题，可降低数据对接传输的操作复杂度。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述第二主控卡中运行有所述网络设备的从虚拟设备管理进程，所述第一主控卡根据所述配置命令请求进行第一主控卡虚拟设备配置，并在配置完成时将所述配置命令请求发送给第二主控卡，包括：
所述主虚拟设备管理进程根据所述配置命令请求进行第一主控卡虚拟设备配置；
在配置完成时，所述主虚拟设备管理进程将所述配置命令请求发送给所述从虚拟设备管理进程。
可见，在本发明实施例中，作为从主控卡的第二主控卡的虚拟设备备份配置操作由作为主主控卡的第一主控卡触发，所述第一主控卡可对第二主控卡的配置操作进行管控，以便于在第一主控卡的虚拟设备发生异常时，所述第二主控卡的虚拟设备可及时接替工作，及时备份。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述第二主控卡根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡发送配置完成的反馈消息，包括：
所述从虚拟设备管理进程根据所述配置命令请求进行第二主控卡虚拟设备配置；
在配置完成时，所述从虚拟设备管理进程生成配置完成的反馈消息；
所述从虚拟设备管理进程将所述反馈消息发送给所述主虚拟设备管理进程。
可见，在本发明实施例中，所述主虚拟设备管理进程及从虚拟设备管理进程均采用自治原则，各虚拟设备管理进程自主控制所属主控卡上虚拟设备的配置操作。由此，可使虚拟设备管理进程具有简单、高效管理性能，减少主、从虚拟设备管理进程之间的牵扯关系，减低业务处理复杂度，避免由于过多牵扯关系导致处理性能下降、出错等问题。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述第一主控卡向客户端设备发送配置成功的通知消息，包括：
所述主虚拟设备管理进程生成配置成功的通知消息，并将所述通知消息发送给所述配置客户端进程；
所述配置客户端进程将所述通知消息发送给客户端设备，以通过所述客户端设备告知用户配置成功。
可见，在本发明实施例中，所述主虚拟设备管理进程只有在确认主、从虚拟设备管理进程都操作成功后，才会生成配置成功的通知消息。由此，可确保从虚拟设备管理进程配置的从虚拟设备随时处于准备就绪的状态，以便于当主虚拟设备异常时，从虚拟设备能够及时接替所述主虚拟设备的工作。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述第一主控卡中还运行有主内存数据库管理进程，在所述第一主控卡获取用于进行虚拟设备配置的配置命令请求的步骤之后，所述方法还包括：
所述主虚拟设备管理进程将所述配置命令请求发送给所述主内存数据库管理进程；
所述主内存数据库管理进程对所述配置命令请求进行保存。
可见，在本发明实施例中，所述主内存数据库管理进程负责进行保存处理，所述主内存数据库管理进程可将所述配置命令请求保存到数据库中，以便于所述网络设备在下一次启动时，能够从数据库直接获取所述配置命令请求，自动重新执行所述配置命令请求，完成对应的虚拟设备配置操作。由此，用户无需再重新输入所述配置命令请求，减少用户操作，提升用户体验。
可选地，结合上述第一方面提供的技术方案，在一种可能的设计中，所述方法还包括：
当所述网络设备检测到异常时，确定所述第一主控卡的主虚拟设备管理进程为所述网络设备的新从虚拟设备管理进程；
确定所述第二主控卡的从虚拟设备管理进程为所述网络设备的新主虚拟设备管理进程。
可见，在本发明实施例中，当所述网络设备检测到异常(比如，虚拟设备异常、主控卡异常、主控卡的关键进程异常等)时，及时进行主从切换处理，保证业务处理的正常运行。
第二方面，本发明实施例提供一种网络设备，所述网络设备包括至少两个主控卡，其中：
第一主控卡，用于获取用于进行虚拟设备配置的配置命令请求；
所述第一主控卡，还用于根据所述配置命令请求进行第一主控卡虚拟设备配置，并在配置完成时将所述配置命令请求发送给第二主控卡；
所述第二主控卡，用于根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡发送配置完成的反馈消息。
在本申请上述第二方面实施例提供的技术方案中，所述第一主控卡可对第二主控卡的配置操作进行管控，以便于在第一主控卡的虚拟设备发生异常时，第二主控卡的虚拟设备可及时接替工作，及时备份。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1是本发明实施例提供的网络设备中主控卡虚拟设备管理系统的方框示意图。
图2是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之一。
图3是本发明第一实施例提供的图2所示的步骤s110的子步骤流程图。
图4是本发明第一实施例提供的图2所示的步骤s120的子步骤流程图。
图5是本发明第一实施例提供的图2所示的步骤s130的子步骤流程图。
图6是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之二。
图7是本发明第一实施例提供的图6所示的步骤s140的子步骤流程图。
图8是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之三。
图9是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之四。
图10是本发明第二实施例提供的运行于网络设备的功能模块框图。
图标：10-网络设备；100-第一主控卡；110-配置客户端模块；120-主虚拟设备管理模块；130-主内存数据库管理模块；200-第二主控卡；210-从虚拟设备管理模块；300-核心处理模块。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。此外，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
本申请发明人在实现本申请实施例提供的技术方案过程中，发现为了解决在虚拟设备发生异常时如何保证业务的正常运行的技术问题，在现有技术中，通常采用在多个虚拟设备之间进行同步备份，当其中一个虚拟设备异常时，进行虚拟设备切换的方式来保证业务正常运行。比如，在现有的一种方案中，从物理设备通过定时主动地向主物理设备获取虚拟设备配置信息来完成虚拟设备的同步配置。该现有方案的缺点在于：由从物理设备主动获取配置信息，主物理设备不知道从物理设备的配置情况。当主物理设备的虚拟设备发生异常时，从物理设备上的虚拟设备可能还没有启动或还未完成虚拟设备配置，此时，从物理设备上的虚拟设备无法及时接替主物理设备上发生异常的虚拟设备的工作，无法做到及时备份。
以上现有技术中的方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本发明实施例针对上述问题所提出的解决方案，都应该是发明人在本发明过程中对本发明做出的贡献。
为了缓解上述问题，本发明实施例提供一种虚拟设备配置方法及网络设备。下面通过以下实施例对本发明提供的虚拟设备配置方法及网络设备进行说明。
请参照图1，图1是本发明实施例提供的网络设备10中主控卡虚拟设备管理系统的方框示意图。所述网络设备10包括至少两个主控卡。其中，图1仅是以所述网络设备10包括两个主控卡(第一主控卡100及第二主控卡200)为例的示意图。所述网络设备10根据实际业务需求还可以包括更多的主控卡。
在本实施例中，所述网络设备10还包括多个业务卡，所述主控卡用于构建虚拟设备，负责数据的转发控制；所述业务卡负责数据报文的实际转发。所述主控卡及业务卡可采用电路集成的物理板卡，所述主控卡及业务卡均可包括cpu、内存及磁盘等资源。
在本实施例中，所述网络设备10可以包括，但不限于，服务器、路由器、交换机、安全网关、pc等设备。
在本实施例中，所述虚拟设备可以是，但不限于，通过虚拟化技术构建的虚拟服务器、虚拟路由器、虚拟交换机、虚拟安全网关、虚拟pc等网络虚拟设备；所述虚拟设备也可以是，通过虚拟化技术构建的由虚拟主控卡、虚拟业务卡、虚拟cpu、虚拟内存、虚拟磁盘等组成的分布式网络虚拟设备。
在本实施例中，所述网络设备10可以采用，但不限于，容器技术、硬件虚拟化技术、多进程技术等构建虚拟设备。其中，优选采用容器技术，容器技术是一种轻量级的虚拟化技术。容器技术可以按需构建容器数量，进而可有效提升工作效率。与硬件虚拟化技术及kvm(keyboardvideomouse，内核虚拟机)技术相比，容器技术可共享一个操作系统，处理效率更高。其中，基于linux系统的linux容器(linuxcontainer)是当前最热的容器技术之一，其能够提供名称空间的隔离和资源的分配。
在本实施例中，下述的实施例将基于linux容器技术对所述虚拟设备配置方法进行说明。需要说明的是：本发明并不限于基于linux容器技术实现本方案，本发明还可以基于vxworks操作系统，普通的多进程技术，或者其它轻量级的容器技术实现本方案。
在本实施例中，下述的实施例将以主、备主控卡为基础的分布式网络系统进行说明，需要说明的是：本发明并不限于分布式网络系统，堆叠式网络系统、集中式系统也同样适用。
可以理解，图1所述的结构仅为示意，网络设备10还包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。
本发明提供一种可读存储介质，所述可读存储介质包括计算机程序。所述计算机程序运行时控制所述可读存储介质所在网络设备10执行下面的虚拟设备配置方法。
第一实施例
本发明实施例提供一种虚拟设备配置方法。请参照图2，图2是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之一。所述方法应用于上述的网络设备10。下面对虚拟设备配置方法的流程进行详细阐述。所述方法包括：步骤s110、步骤s120及步骤s130。
步骤s110，第一主控卡100获取用于进行虚拟设备配置的配置命令请求。
请再次参照图1，在本实施例中，所述第一主控卡100中运行有配置客户端进程，所述网络设备10的主虚拟设备管理进程，以及用于对所述网络设备10中运行的进程进行集中管控的核心处理进程。
请参照图3，图3是本发明第一实施例提供的图2所示的步骤s110的子步骤流程图。所述步骤s110包括子步骤s111及子步骤s112。
子步骤s111，所述配置客户端进程通过串口获取用于进行虚拟设备配置的配置命令请求。
在本实施例中，所述网络设备10与客户端设备通信连接，用户可以通过客户端设备提供的客户端界面(比如，securecrt，一款安全终端配置软件)登录网络设备10。用户通过在客户端界面输入用于进行虚拟设备配置的配置命令请求来告知网络设备10进行虚拟设备配置。
其中，用户可根据配置命令对网络设备10进行相应的虚拟设备配置操作，比如，虚拟设备创建、虚拟设备启动、虚拟设备关闭、虚拟设备删除等。
在本实施例中，所述客户端设备可将用户输入的配置命令请求(比如，创建一个虚拟设备：createvdev1)通过串口(串行接口，通常指com接口)传递给所述配置客户端进程。
子步骤s112，所述配置客户端进程对所述配置命令请求进行封装，并将经过封装的配置命令请求发送给所述主虚拟设备管理进程。
在本实施例中，所述配置客户端进程对所述配置命令请求进行必要封装后发送给所述主虚拟设备管理进程。
在本实施例中，为了尽可能地节约系统资源，可对虚拟设备管理进程进行动态启动，即所述主虚拟设备管理进程和从虚拟设备管理进程的默认状态是未启动状态，在需要时才会被启动进行业务处理。由此，所述配置客户端进程传输所述配置命令请求时，虚拟设备管理进程可能处于未启动状态，此时，核心处理进程可先启动所述主虚拟设备管理进程及从虚拟设备管理进程，之后，所述配置客户端进程再将所述配置命令请求发送给所述主虚拟设备管理进程。
步骤s120，所述第一主控卡100根据所述配置命令请求进行第一主控卡虚拟设备配置，并在配置完成时将所述配置命令请求发送给第二主控卡200。
请再次参照图1，在本实施例中，所述第二主控卡200中运行有所述网络设备10的从虚拟设备管理进程。
请参照图4，图4是本发明第一实施例提供的图2所示的步骤s120的子步骤流程图。所述步骤s120包括子步骤s121及子步骤s122。
子步骤s121，所述主虚拟设备管理进程根据所述配置命令请求进行第一主控卡虚拟设备配置。
在本实施例中，所述主虚拟设备管理进程根据所述配置命令请求在所述第一主控卡100中进行第一主控卡虚拟设备配置。例如，假设所述主虚拟设备管理进程接收到的所述配置命令请求是createvdev1，所述主虚拟设备管理进程可通过linux系统提供的容器创建接口在所述第一主控卡100中创建一个用于承载虚拟设备的容器vdev1。
子步骤s122，在配置完成时，所述主虚拟设备管理进程将所述配置命令请求发送给所述从虚拟设备管理进程。
在本实施例中，当配置完成时，所述主虚拟设备管理进程可将所述配置命令请求发送给运行于所述第二主控卡200的从虚拟设备管理进程，以使所述第二主控卡200进行虚拟设备备份配置。
在本实施例中，本方案的虚拟设备管理进程采用可主从设计结构，可设置为，但不限于，一主一从、一主多从等方式。其中，第一主控卡100可作为主主控卡，第一主控卡100中运行的虚拟设备管理进程可作为所述网络设备10的主虚拟设备管理进程，第二主控卡200可作为从主控卡，第二主控卡200中运行的虚拟设备管理进程可作为所述网络设备10的从虚拟设备管理进程。
在本实施例中，由于所述第一主控卡100将所述配置命令请求发送给所述第二主控卡200之后，所述第二主控卡200才会进行虚拟设备备份配置。由此，作为从主控卡的第二主控卡200的虚拟设备备份配置操作由作为主主控卡的第一主控卡100触发，所述第一主控卡100可对第二主控卡200的配置操作进行管控，以便于在第一主控卡100的虚拟设备发生异常时，所述第二主控卡200的虚拟设备可及时接替工作，及时备份。
步骤s130，所述第二主控卡200根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡100发送配置完成的反馈消息。
请参照图5，图5是本发明第一实施例提供的图2所示的步骤s130的子步骤流程图。所述步骤s130包括子步骤s131、子步骤s132及子步骤s133。
子步骤s131，所述从虚拟设备管理进程根据所述配置命令请求进行第二主控卡虚拟设备配置。
在本实施例中，所述从虚拟设备管理进程接收到所述主虚拟设备管理进程传输的配置命令请求后，可根据所述配置命令请求在所述第二主控卡200中进行第二主控卡虚拟设备配置。例如，假设所述配置命令请求是createvdev1，所述从虚拟设备管理进程可通过linux系统提供的容器创建接口在所述第二主控卡200中创建一个与上述第一主控卡100中的配置的容器vdev1相对应的容器vdev1，以通过所述容器vdev1承载所述第二主控卡200上的虚拟设备。
在本实施例中，当第一主控卡100及第二主控卡200中的容器均创建完成时，所述主虚拟设备管理进程与所述从虚拟设备管理进程可根据预设协商规则进行协商，协商出两个容器的主从关系，以确定对外提供服务的主容器。例如，如图1所示，对于容器1，所述第一主控卡100中的容器1可作为对外提供服务的主容器，所述第二主控卡200中的容器1作为从容器；而对于容器2，则相反。其中，在默认情况下，通常将所述第一主控卡100中的容器(vdev1)作为对外提供服务的主容器。
在本实施例中，基于同一条配置命令请求，在所述第二主控卡200上进行的第二主控卡虚拟设备配置操作需要与在所述第一主控卡100上进行的第一主控卡虚拟设备配置操作相对应。
在本实施例中，所述第一主控卡100和/或第二主控卡200中均可创建多个用于承载不同类型虚拟设备的容器。其中，所述第一主控卡100与所述第二主控卡200中的容器需要相互对应。例如，如图1所示，第一主控卡100的主容器1与第二主控卡200的从容器1对应，第一主控卡100的从容器2与第二主控卡200的主容器2对应。
子步骤s132，在配置完成时，所述从虚拟设备管理进程生成配置完成的反馈消息。
子步骤s133，所述从虚拟设备管理进程将所述反馈消息发送给所述主虚拟设备管理进程。
在本实施例中，当所述从虚拟设备管理进程配置操作成功时，所述从虚拟设备管理进程可生成配置完成的反馈消息，并将所述反馈消息发送给所述主虚拟设备管理进程。所述主虚拟设备管理进程接收到所述反馈消息时，可获知所述从虚拟设备管理进程已完成配置，准备就绪，可随时接替工作。
在本实施例中，所述主虚拟设备管理进程及从虚拟设备管理进程均采用自治原则，各虚拟设备管理进程自主控制所属主控卡上虚拟设备的配置操作(比如，创建、启动、关闭、删除等)。由此，可使虚拟设备管理进程具有简单、高效管理性能，减少主、从虚拟设备管理进程之间的牵扯关系，减低业务处理复杂度，避免由于过多牵扯关系导致处理性能下降、出错等问题。
请参照图6，图6是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之二。所述方法还包括：步骤s140。
步骤s140，所述第一主控卡100向客户端设备发送配置成功的通知消息。
请参照图7，图7是本发明第一实施例提供的图6所示的步骤s140的子步骤流程图。所述步骤s140包括子步骤s141及子步骤s142。
子步骤s141，所述主虚拟设备管理进程生成配置成功的通知消息，并将所述通知消息发送给所述配置客户端进程。
在本实施例中，当所述主虚拟设备管理进程接收到从虚拟设备管理进程发送的反馈消息时，所述主虚拟设备管理进程可生成配置成功的通知消息，并将所述通知消息发送给所述配置客户端进程。
子步骤s142，所述配置客户端进程将所述通知消息发送给客户端设备，以通过所述客户端设备告知用户配置成功。
在本实施例中，所述配置客户端进程可通过串口将配置成功的通知消息发送给客户端设备，所述客户端设备通过securecrt界面提示用户操作成功。
在本实施例中，所述主虚拟设备管理进程只有在确认主、从虚拟设备管理进程都操作成功后，才会生成配置成功的通知消息。由此，可确保从虚拟设备管理进程配置的从虚拟设备随时处于准备就绪的状态，以便于当主虚拟设备异常时，从虚拟设备能够及时接替所述主虚拟设备的工作。
在本实施例中，如果配置失败，所述主虚拟设备管理进程可重新进行配置，或者生成并发送配置失败的通知消息，以告知用户，并等待用户的进一步指示。
请参照图8，图8是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之三。在上述步骤s110之后，所述方法还包括：步骤s150及步骤s155。其中，步骤s150及步骤s155只需保证在步骤s110之后执行即可，比如，步骤s150及步骤s155也可在步骤s140之后执行。
请再次参照图1，在本实施例中，所述第一主控卡100中还运行有主内存数据库管理进程。
步骤s150，所述主虚拟设备管理进程将所述配置命令请求发送给所述主内存数据库管理进程。
在本实施例中，所述主虚拟设备管理进程获取所述配置命令请求后，可将所述配置命令请求发送给所述主内存数据库管理进程。
步骤s155，所述主内存数据库管理进程对所述配置命令请求进行保存。
在本实施例中，所述主内存数据库管理进程负责进行配置序列化保存处理，所述主内存数据库管理进程可将所述配置命令请求保存到数据库中，以便于所述网络设备10在下一次启动时，能够从数据库直接获取所述配置命令请求，自动重新执行所述配置命令请求，完成对应的虚拟设备配置操作。由此，用户无需再重新输入所述配置命令请求，减少用户操作，提升用户体验。
请参照图9，图9是本发明第一实施例提供的虚拟设备配置方法的步骤流程图之四。所述方法还包括：步骤s160及步骤s165。
步骤s160，当所述网络设备10检测到异常时，确定所述第一主控卡100的主虚拟设备管理进程为所述网络设备10的新从虚拟设备管理进程。
步骤s165，确定所述第二主控卡200的从虚拟设备管理进程为所述网络设备10的新主虚拟设备管理进程。
在本实施例中，所述主、从虚拟设备管理进程的主从关系不是一成不变的。当所述网络设备10检测到异常(比如，虚拟设备异常、主控卡异常、主控卡的关键进程异常等)时，需要进行主从切换处理。此时，所述网络设备10确定所述第一主控卡100的主虚拟设备管理进程为所述网络设备10的新从虚拟设备管理进程。确定所述第二主控卡200的从虚拟设备管理进程为所述网络设备10的新主虚拟设备管理进程。即，所述第二主控卡200中运行虚拟设备管理进程升级为新的主虚拟设备管理进程，分布式通信线路身份变为主，负责监听配置客户端进程传输的配置命令请求。所述第一主控卡100中运行虚拟设备管理进程降级为新的从虚拟设备管理进程，分布式通信线路身份变为从，不再监听配置客户端进程传输的配置命令请求。同时，第二主控卡200的内存数据库管理进程升级为主内存数据库管理进程，负责维护数据库配置。第一主控卡100的内存数据库管理进程降级为从内存数据库管理进程，不再维护数据库配置。
在本实施例中，需要说明的是，当主控卡中的进程(比如，虚拟设备管理进程、内存数据库管理进程等非关键进程)发生异常时，并不会引起主控卡的主、从关系切换。避免频繁切换，增加系统开销。该进程发生异常时可通过调试或重新启动等措施，以重新恢复正常。
第二实施例
请参照图10，图10是本发明第二实施例提供的运行于网络设备10的功能模块框图。所述网络设备10包括第一主控卡100及第二主控卡200。
在本实施例中，所述第一主控卡100包括：配置客户端模块110及所述网络设备10的主虚拟设备管理模块120。所述第二主控卡200包括：所述网络设备10的从虚拟设备管理模块210。
所述配置客户端模块110，用于通过串口获取用于进行虚拟设备配置的配置命令请求。
所述配置客户端模块110，还用于对所述配置命令请求进行封装，并将经过封装的配置命令请求发送给所述主虚拟设备管理模块120。
所述主虚拟设备管理模块120，用于根据所述配置命令请求进行第一主控卡虚拟设备配置。
在配置完成时，所述主虚拟设备管理模块120，还用于将所述配置命令请求发送给所述从虚拟设备管理模块210。
所述从虚拟设备管理模块210，用于根据所述配置命令请求进行第二主控卡虚拟设备配置。
在配置完成时，所述从虚拟设备管理模块210，还用于生成配置完成的反馈消息。
所述从虚拟设备管理模块210，还用于将所述反馈消息发送给所述主虚拟设备管理模块120。
所述主虚拟设备管理模块120，还用于生成配置成功的通知消息，并将所述通知消息发送给所述配置客户端模块110。
所述配置客户端模块110，还用于将所述通知消息发送给客户端设备，以通过所述客户端设备告知用户配置成功。
请再次参照图10，所述第一主控卡100还包括：主内存数据库管理模块130。
所述主虚拟设备管理模块120，还用于将所述配置命令请求发送给所述主内存数据库管理模块130。
所述主内存数据库管理模块130，用于对所述配置命令请求进行保存。
请再次参照图10，所述网络设备10还包括：核心处理模块300。
当所述网络设备10检测到异常时，所述核心处理模块300，用于确定所述第一主控卡100的主虚拟设备管理模块120为所述网络设备10的新从虚拟设备管理模块。
所述核心处理模块300，还用于确定所述第二主控卡200的从虚拟设备管理模块210为所述网络设备10的新主虚拟设备管理模块。
在本实施例中，所述配置客户端模块110用于执行图3中的子步骤s111及子步骤s112，以及图7中的子步骤s142。所述主虚拟设备管理模块120用于执行图4中的子步骤s121及子步骤s122，图7中的子步骤s141，以及图8中的步骤s150。所述从虚拟设备管理模块210用于执行图5中的子步骤s131、子步骤s132及子步骤s133。所述主内存数据库管理模块130用于执行图8中的步骤s155。所述核心处理模块300用于执行图9中的步骤s160及步骤s165。
综上所述，本发明实施例提供一种虚拟设备配置方法及网络设备。所述方法应用于包括至少两个主控卡的网络设备，所述方法包括：第一主控卡获取用于进行虚拟设备配置的配置命令请求。所述第一主控卡根据所述配置命令请求进行第一主控卡虚拟设备配置，并在配置完成时将所述配置命令请求发送给第二主控卡。所述第二主控卡根据所述配置命令请求进行第二主控卡虚拟设备配置，并在配置完成时向所述第一主控卡发送配置完成的反馈消息。
由此，第一主控卡可对第二主控卡的配置操作进行管控，以便于在第一主控卡的虚拟设备发生异常时，第二主控卡的虚拟设备可及时接替工作，及时备份。
并且，第一主控卡及第二主控卡均采用自治原则，各主控卡自主控制各主控卡上虚拟设备的配置操作。可进行简单、高效地配置管理，减少各主控卡之间的牵扯关系，减低业务处理复杂度。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。