- Devel - libvirt List Archives

[libvirt] [PATCH] LXC: Set default driver for image backed filesystems
by Daniel P. Berrange 09 Jul '13

09 Jul '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> If no explicit driver is set for an image backed filesystem, set it to use the loop driver (if raw) or nbd driver (if non-raw) Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_controller.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 568227f..ef35c05 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -457,6 +457,14 @@ static int virLXCControllerSetupLoopDevices(virLXCControllerPtr ctrl) if (fs->type != VIR_DOMAIN_FS_TYPE_FILE) continue; + if (fs->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_DEFAULT) { + if (fs->format == VIR_STORAGE_FILE_RAW || + fs->format == VIR_STORAGE_FILE_NONE) + fs->fsdriver = VIR_DOMAIN_FS_DRIVER_TYPE_LOOP; + else + fs->fsdriver = VIR_DOMAIN_FS_DRIVER_TYPE_NBD; + } + if (fs->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_LOOP) { if (fs->format != VIR_STORAGE_FILE_RAW && fs->format != VIR_STORAGE_FILE_NONE) { -- 1.8.3.1

2 1

[libvirt] [Qeustion] NPIV support on guest
by Ren Mingxin 09 Jul '13

09 Jul '13

Hi, It seems this is a old question, but I couldn't get a exact answer via historical mails: How to assign vhba to guest now? It'll be much appreciated if exact xml format/qemu commandcan be showed. And, it seems that persistent vhba hasn't been supported by libvirt, yes? Thanks, Ren

1 0

[libvirt] [sandbox][PATCH] Fix nits in virt-sandbox-service when raise ValueError
by Wayne Sun 09 Jul '13

09 Jul '13

Put error msg in list when raise ValueError. This fix is for bug: [virt-sandbox-service] execute command with unsupported URI error msg is not right https://bugzilla.redhat.com/show_bug.cgi?id=967705 Signed-off-by: Wayne Sun <gsun(a)redhat.com> --- bin/virt-sandbox-service | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/bin/virt-sandbox-service b/bin/virt-sandbox-service index 4496b29..1db3c09 100755 --- a/bin/virt-sandbox-service +++ b/bin/virt-sandbox-service @@ -878,7 +878,7 @@ def sandbox_list(args): def sandbox_reload(args): config = read_config(args.name) if isinstance(config, gi.repository.LibvirtSandbox.ConfigServiceGeneric): - raise ValueError(_("Generic Containers do not support reload")) + raise ValueError([_("Generic Containers do not support reload")]) container = SystemdContainer(uri = args.uri, config = config) container.reload(args.unitfiles) @@ -931,7 +931,7 @@ def fullpath(cmd): def execute(args): if args.uri != "lxc:///": - raise ValueError(_("Can only execute commands inside of linux containers.")) + raise ValueError([_("Can only execute commands inside of linux containers.")]) myexec = [ "virsh", "-c", args.uri, "lxc-enter-namespace" ] # myexec = [ "virt-sandbox-service-util", "execute" ] -- 1.7.1

3 2

[libvirt] [PATCH] lxc: Create /dev/tty within a container
by Richard Weinberger 09 Jul '13

09 Jul '13

Many applications use /dev/tty to read from stdin. E.g. zypper on openSUSE. Let's create this device node to unbreak those applications. As /dev/tty is a synonym for the current controlling terminal it cannot harm the host or any other containers. Signed-off-by: Richard Weinberger <richard(a)nod.at> --- src/lxc/lxc_container.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 181f6c8..9ab64a1 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -837,6 +837,7 @@ static int lxcContainerPopulateDevices(char **ttyPaths, size_t nttyPaths) { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_FULL, 0666, "/dev/full" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_RANDOM, 0666, "/dev/random" }, { LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_URANDOM, 0666, "/dev/urandom" }, + { LXC_DEV_MAJ_TTY, LXC_DEV_MIN_TTY, 0666, "/tty" }, }; const struct { const char *src; -- 1.8.3

2 1

[libvirt] [PATCH] domain controller index check
by jmiao＠redhat.com 09 Jul '13

09 Jul '13

From: Jincheng Miao <jmiao(a)redhat.com> The index of the controller should not be less than zero. So use virStrToLong_ui() to check the controller index in virDomainControllerDefParseXML(). --- src/conf/domain_conf.c | 2 +- src/conf/domain_conf.h | 2 +- src/qemu/qemu_command.c | 2 +- src/vmx/vmx.c | 3 +-- 4 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 402e6e9..2831edf 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5593,7 +5593,7 @@ virDomainControllerDefParseXML(xmlNodePtr node, idx = virXMLPropString(node, "index"); if (idx) { - if (virStrToLong_i(idx, NULL, 10, &def->idx) < 0) { + if (virStrToLong_ui(idx, NULL, 10, &def->idx) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Cannot parse controller index %s"), idx); goto error; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index da83eb6..7897b4b 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -790,7 +790,7 @@ struct _virDomainVirtioSerialOpts { /* Stores the virtual disk controller configuration */ struct _virDomainControllerDef { int type; - int idx; + unsigned int idx; int model; /* -1 == undef */ unsigned int queues; union { diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 46db28a..7fd1cbf 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1585,7 +1585,7 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def, for (i = 0; i < def->ncontrollers; i++) { if (def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI) { - if (def->controllers[i]->idx > max_idx) + if ((int)def->controllers[i]->idx > max_idx) max_idx = def->controllers[i]->idx; } } diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 5464d13..deddfaa 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -1664,8 +1664,7 @@ virVMXParseConfig(virVMXContext *ctx, for (controller = 0; controller < def->ncontrollers; ++controller) { if (def->controllers[controller]->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) { - if (def->controllers[controller]->idx < 0 || - def->controllers[controller]->idx > 3) { + if (def->controllers[controller]->idx > 3) { virReportError(VIR_ERR_INTERNAL_ERROR, _("SCSI controller index %d out of [0..3] range"), def->controllers[controller]->idx); -- 1.7.1

3 2

[libvirt] [PATCH] scsi: Fix construction of sysfs device path
by Viktor Mihajlovski 09 Jul '13

09 Jul '13

The device bus value was used instead of the device target when building the sysfs device path. Trivial. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- Should probably go into the 1.0.6 maintenance branch as well. src/util/virscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virscsi.c b/src/util/virscsi.c index 4870307..726121b 100644 --- a/src/util/virscsi.c +++ b/src/util/virscsi.c @@ -218,7 +218,7 @@ virSCSIDeviceNew(const char *adapter, goto cleanup; if (virAsprintf(&dev->name, "%d:%d:%d:%d", dev->adapter, - dev->bus, dev->bus, dev->unit) < 0 || + dev->bus, dev->target, dev->unit) < 0 || virAsprintf(&dev->sg_path, "/dev/%s", sg) < 0) { virReportOOMError(); goto cleanup; -- 1.7.9.5

2 1

[libvirt] [ANNOUNCE] libvirt-glib 0.1.7 release
by Daniel P. Berrange 08 Jul '13

08 Jul '13

I am pleased to announce that a new release of the libvirt-glib package, version 0.1.7, is now available from ftp://libvirt.org/libvirt/glib/ The packages are GPG signed with Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R) Changes in this release: - Fix memory leaks in domain memory setters - Add APIs for configuration sdl/rdp/desktop graphics modes - Add getter APIs for domain channel devices - Add getter APIs for storage pools - Add API for getting/setting virt type - Add getter APIs for storage pool schema - Add base framework for i18n of error messages - Fix annotation of gvir_init_object - Add getter/setter APIs for disk driver format - Add APIs for domain snapshot schema - Add APIs to access domain chardev source - Add API to access domain device aliases libvirt-glib comprises three distinct libraries: - libvirt-glib - Integrate with the GLib event loop and error handling - libvirt-gconfig - Representation of libvirt XML documents as GObjects - libvirt-gobject - Mapping of libvirt APIs into the GObject type system NB: While libvirt aims to be API/ABI stable forever, with libvirt-glib we are not yet guaranteeing that libvirt-glib libraries are API/ABI permanently stable. As of the 0.0.8 release, we have tentatively frozen the API/ABI with the intent of being longterm stable hereafter, but there is still a small chance we might find flaws requiring an API/ABI change. The likelihood of this is low, however, and we will strive to avoid it. Follow up comments about libvirt-glib should be directed to the regular libvir-list(a)redhat.com development list. Thanks to all the people involved in contributing to this release. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCHv2 0/2] selinux: Always label FD's passed to qemu
by Peter Krempa 08 Jul '13

08 Jul '13

This second version just always creates the imagelabel field that will be used to label the passed FDs appropriately and always even if relabeling is not requested. The rest of the code paths are still relabeled only if relabeling is enabled. Peter Krempa (2): selinux: Cleanup coding style selinux: Always generate imagelabel src/security/security_selinux.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) -- 1.8.2.1

2 6

[libvirt] RFC: Introduce API to query IP addresses for given domain
by Nehal J. Wani 08 Jul '13

08 Jul '13

Hello, fellow developers! I am a GSoC candidate this year working for libvirt.org. My project is "Introduce API to query IP addresses for given domain". The discussion regarding this feature had started here: http://www.mail-archive.com/libvir-list@redhat.com/msg51857.html and then Michal had sent a patch too (refer: http://www.mail-archive.com/libvir-list@redhat.com/msg57141.html) But it was not pushed upstream due to lack of extensibility. So far I've come up with an API and I want to get your opinion before I start writing the rest so I don't follow the wrong direction. Following are the valid commands: domifaddr <domain-name> domifaddr <domain-name> <interface-name> domifaddr <domain-name> <interface-name> <method> domifaddr <domain-name> <method> methods: (i) Querying qemu-guest-agent (ii) Getting info from dnsmasq.leases file (iii) Using the nwfilter to snoop the traffic If no method is mentioned, qemu-guest-agent will be used. Previous attempts by Michal had used structs and xml. Structs bring in restrictions and xml has to be parsed. Hence I am not planning to continue with either of these. As a start, I would like to know your comments about my API which queries the qemu-guest-agent and returns the results in virTypedParameter **params. Format(JSON) in which the qemu guest agent returns info: [{"name":"lo", "ip-addresses": [{"ip-address-type":"ipv4","ip-address":"127.0.0.1","prefix":8}, {"ip-address-type":"ipv6","ip-address":"::1","prefix":128}], "hardware-address":"00:00:00:00:00:00"}, {"name":"eth0", "ip-addresses": [{"ip-address-type":"ipv4","ip-address":"192.168.122.42","prefix":24}, {"ip-address-type":"ipv6","ip-address":"fe80::5054:ff:fe09:d240","prefix":64}], "hardware-address":"52:54:00:09:d2:40"}] //Possible 1-D Structure (A little hassle to maintain) params[0] = {"iface-count",int,2} params[1] = {"iface-name",string,"lo"} params[2] = {"iface-hwaddr",string,"00:00:00:00:00:00"} params[3] = {"iface-addr-count",int,2} params[4] = {"iface-addr-type",string,"ipv4"} params[5] = {"iface-addr",string,"127.0.0.1"} params[6] = {"iface-addr-prefix",int,8} params[7] = {"iface-addr-type",string,"ipv6"} params[8] = {"iface-addr",string,"::1"} params[9] = {"iface-addr-prefix",int,128} .... .... .... //2D Structure: (Not very hasslefree, but easier to maintain as one interface per row) params[0] = {"iface-name",string,"lo"}{"iface-hwaddr",string,"00:00:00:00:00:00"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"127.0.0.1"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"::1"}{"iface-addr-prefix",int,128} params[1] = {"iface-name",string,"eth0"}{"iface-hwaddr",string,"52:54:00:09:d2:40"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"192.168.122.42"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"fe80::5054:ff:fe09:d240"}{"iface-addr-prefix",int,64} Function definitions that I intend to use are: static int remoteDispatchDomainInterfacesAddresses( virNetServerPtr server ATTRIBUTE_UNUSED, virNetServerClientPtr client, virNetMessagePtr msg ATTRIBUTE_UNUSED, virNetMessageErrorPtr rerr, remote_domain_interfaces_addresses_args *args, remote_domain_interfaces_addresses_ret *ret) int virDomainInterfacesAddresses (virDomainPtr dom, virTypedParameterPtr *params, int *nparams, unsigned int flags); typedef int (*virDrvDomainInterfacesAddresses) (virDomainPtr dom, virTypedParameterPtr *params, int *nparams, unsigned int flags); int virDomainInterfacesAddresses (virDomainPtr dom, virTypedParameterPtr *params, int *nparams, unsigned int flags) int qemuAgentGetInterfaces(qemuAgentPtr mon, virTypedParameterPtr *params, int *nparams) int qemuAgentGetInterfaces(qemuAgentPtr mon, virTypedParameterPtr *params, int *nparams); static int qemuDomainInterfacesAddresses(virDomainPtr dom, virTypedParameterPtr *params, int *nparams, unsigned int flags) static int remoteDomainInterfacesAddresses(virDomainPtr dom, virTypedParameterPtr *params, int *nparams, unsigned int flags) static bool cmdDomIfAddr(vshControl *ctl, const vshCmd *cmd) Also, It will be helpful to know whether we want the client to first query for the number of parameters and then send the request or have the server side allocate appropriate memory and return the result once in for all. In the latter case, I'll be using something of the kind virTypedParameterPtr ***params. Thanking You, Nehal J. Wani UG2, BTech CS+MS(CL) IIIT-Hyderabad http://commanlinewani.blogspot.com

4 8

[libvirt] [libvirt-1.0.5]deadlock in child process after call function backtrace, any suggestions is appreciate!
by Caizhifeng 08 Jul '13

08 Jul '13

Hi ALL, In order to catch the calltrace of deadlock in libvirtd, I modified the function virMutexLock as follows: struct virMutex { pthread_mutex_t lock; void *trace[TRACE_SIZE]; //added for test int ntrace; //added for test }; void virMutexLock(virMutexPtr m) { struct timespec ts; if (0 == clock_gettime(CLOCK_REALTIME, &ts)) { ts.tv_sec += LOCK_TIMEOUT; if (pthread_mutex_timedlock(&m->lock, &ts) == ETIMEDOUT) { if (m->ntrace > 0) virLogBacktrace(m->ntrace, m->trace); pthread_mutex_lock(&m->lock); } m->ntrace = backtrace(m->trace, TRACE_SIZE); //record the call trace information. } else { pthread_mutex_lock(&m->lock); } } The original is : void virMutexLock(virMutexPtr m){ pthread_mutex_lock(&m->lock); } But, unfortunatly, sometimes, deadlock happened in child process after virFork, the father libvirtd process' pid is 2987, and the child libvirtd process id is 29509, which is forked in order to run a shell script. root@cvk143:~# ps -ef | grep libvirtd root 2987 1 52 08:36 ? 00:40:38 /usr/sbin/libvirtd -d root 29509 2987 0 09:38 ? 00:00:00 /usr/sbin/libvirtd -d root@cvk143:~# the child process's call trace is as follow: (gdb) bt #0 0x00007f4d5e7fd89c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f4d5e7f9080 in _L_lock_903 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f4d5e7f8f19 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f4d5e5607db in dl_iterate_phdr () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007f4d5c3c88b6 in _Unwind_Find_FDE () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #5 0x00007f4d5c3c5d70 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #6 0x00007f4d5c3c6490 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #7 0x00007f4d5c3c6d3e in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #8 0x00007f4d5e53b1c8 in backtrace () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x00007f4d5f6f8c92 in virMutexLock (m=0x7f4d5fadedc0) at util/virthreadpthread.c:128 #10 0x00007f4d5f6d0a3d in virLogLock () at util/virlog.c:152 #11 0x00007f4d5f6d0f66 in virLogReset () at util/virlog.c:311 #12 0x00007f4d5f6b3139 in virFork (pid=0x7f4d5a1a4310) at util/vircommand.c:281 #13 0x00007f4d5f6b3b06 in virExec (cmd=0x7f4d2000a6f0) at util/vircommand.c:493 #14 0x00007f4d5f6b8a34 in virCommandRunAsync (cmd=0x7f4d2000a6f0, pid=0x0) at util/vircommand.c:2340 #15 0x00007f4d5f6b815c in virCommandRun (cmd=0x7f4d2000a6f0, exitstatus=0x7f4d5a1a4728) at util/vircommand.c:2191 #16 0x00007f4d5f6b4bdd in virRun (argv=0x7f4d5a1a4730, status=0x7f4d5a1a4728) at util/vircommand.c:776 #17 0x00007f4d60231006 in virStorageNFSPoolCheckSub (hostName=0x7f4d50011630 "192.168.0.6", hostDir=0x7f4d50014560 "/vms/isos") at storage/storage_backend.c:165 #18 0x00007f4d602312fa in virStoragePoolCheckFirst (pool=0x7f4d5000dcc0) at storage/storage_backend.c:255 #19 0x00007f4d602383af in virStorageBackendFileSystemRefresh (conn=0x7f4d3c0010a0, pool=0x7f4d5000dcc0) at storage/storage_backend_fs.c:887 #20 0x00007f4d6022c458 in storagePoolRefresh (obj=0x7f4d200012e0, flags=0) at storage/storage_driver.c:1705 #21 0x00007f4d5f7ac445 in virStoragePoolRefresh (pool=0x7f4d200012e0, flags=0) at libvirt.c:12936 #22 0x00007f4d6015c62f in remoteDispatchStoragePoolRefresh (server=0x7f4d60bb4ec0, client=0x7f4d60bbc380, msg=0x7f4d60bbcae0, rerr=0x7f4d5a1a4af0, args=0x7f4d2000f0b0) at remote_dispatch.h:12867 #23 0x00007f4d6015c527 in remoteDispatchStoragePoolRefreshHelper (server=0x7f4d60bb4ec0, client=0x7f4d60bbc380, msg=0x7f4d60bbcae0, rerr=0x7f4d5a1a4af0, args=0x7f4d2000f0b0, ret=0x7f4d200144f0) at remote_dispatch.h:12845 #24 0x00007f4d5f7fe7d5 in virNetServerProgramDispatchCall (prog=0x7f4d60bbfc90, server=0x7f4d60bb4ec0, client=0x7f4d60bbc380, msg=0x7f4d60bbcae0) at rpc/virnetserverprogram.c:439 #25 0x00007f4d5f7fe34e in virNetServerProgramDispatch (prog=0x7f4d60bbfc90, server=0x7f4d60bb4ec0, client=0x7f4d60bbc380, msg=0x7f4d60bbcae0) at rpc/virnetserverprogram.c:305 #26 0x00007f4d5f7f72ea in virNetServerProcessMsg (srv=0x7f4d60bb4ec0, client=0x7f4d60bbc380, prog=0x7f4d60bbfc90, msg=0x7f4d60bbcae0) at rpc/virnetserver.c:162 #27 0x00007f4d5f7f73cd in virNetServerHandleJob (jobOpaque=0x7f4d60bbdbf0, opaque=0x7f4d60bb4ec0) at rpc/virnetserver.c:183 #28 0x00007f4d5f6f9602 in virThreadPoolWorker (opaque=0x7f4d60b9aa40) at util/virthreadpool.c:144 #29 0x00007f4d5f6f8fd6 in virThreadHelper (data=0x7f4d60b9a9b0) at util/virthreadpthread.c:212 #30 0x00007f4d5e7f6e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #31 0x00007f4d5e5244bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #32 0x0000000000000000 in ?? () (gdb) .............. I googled and found the similar deadlock call trace,which can be found in this link: code.google.com/p/gperftools/issues/detail?id=66 , but it is not a situation in libvirtd. ...... Labels: -Priority-Medium Priority-Low Jan 22, 2013 #32 DarkAge...(a)gmail.com Please note the glibc unwinder also uses dl_iterate_phdr, and takes several locks during backtrace generation in _Unwind_Find_FDE. #0 0x00007ffff7bc6e80 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff7212fdb in dl_iterate_phdr () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff6be28b6 in _Unwind_Find_FDE () from /lib/libgcc_s.so.1 #3 0x00007ffff6bdfd70 in ?? () from /lib/libgcc_s.so.1 #4 0x00007ffff6be0d7d in _Unwind_Backtrace () from /lib/libgcc_s.so.1 #5 0x00007ffff71ed9c8 in backtrace () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x000000000040fdb5 in glibc_backtrace (error=<synthetic pointer>, buffer=0x7fffffffdd10, size=<optimized out>, ucontext=<optimized out>) ...... Is there anyone ever encouter the similar problem? Would be great if someone can help me on this. Thank you very much. ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

3 2