ovsdb-server(1) Open vSwitch Manual ovsdb-server(1)

ovsdb-server - سرور پایگاه داده Open vSwitch

ovsdb-server [database]... [relay:schema_name:remote]... [--remote=remote]... [--config-file=file] [--run=command]

گزینه‌های دیمن (Daemon options):
[--pidfile[=pidfile]] [--overwrite-pidfile] [--detach] [--no-chdir] [--no-self-confinement]
گزینه‌های ثبت وقایع (Logging options):
[-v[module[:destination[:level]]]]...
[--verbose[=module[:destination[:level]]]]...
[--log-file[=file]]
گزینه‌های فعال-پشتیبان (Active-backup options):
[--sync-from=server] [--sync-exclude-tables=db:table[,db:table]...] [--active]
گزینه‌های زیرساخت کلید عمومی (Public key infrastructure options):
[--private-key=privkey.pem]
[--certificate=cert.pem]
[--ca-cert=cacert.pem]
[--ssl-server-name=servername]
[--bootstrap-ca-cert=cacert.pem]
[--peer-ca-cert=peer-cacert.pem]
گزینه‌های اتصال SSL/TLS (SSL/TLS connection options):
[--ssl-protocols=protocols]
[--ssl-ciphers=ciphers]
[--ssl-ciphersuites=ciphersuites]
گزینه‌های مدیریت زمان اجرا (Runtime management options):
--unixctl=socket
گزینه‌های بازپخش (Replay options):
[--record[=directory]] [--replay[=directory]]
گزینه‌های عمومی (Common options):
[-h | --help] [-V | --version]

برنامه ovsdb-server رابط‌های RPC را برای یک یا چند پایگاه داده Open vSwitch (کوتاه‌نوشت OVSDB) فراهم می‌کند. این برنامه از اتصالات کلاینت JSON-RPC روی سوکت‌های دامنه یونیکس یا TCP/IP فعال یا غیرفعال پشتیبانی می‌کند. برای آشنایی با OVSDB و نحوه پیاده‌سازی آن در Open vSwitch، به ovsdb(7) مراجعه کنید.

هر فایل OVSDB می‌تواند در خط فرمان با عنوان database مشخص شود. پایگاه‌های داده بازپخش (relay) می‌توانند در خط فرمان به‌صورت relay:schema_name:remote تعیین گردند. برای شرح تفصیلی آرگومان پایگاه داده relay، به ovsdb(7) مراجعه فرمایید. اگر هیچ‌یک از فایل‌های پایگاه داده یا پایگاه‌های داده relay مشخص نشوند، مقدار پیش‌فرض /etc/openvswitch/conf.db است. فایل‌های پایگاه داده باید از قبل با استفاده از دستورهای create، create-cluster، یا join-cluster ابزار ovsdb-tool ایجاد و راه‌اندازی اولیه شده باشند.

همه انواع پایگاه داده را می‌توان به‌صورت جایگزین با استفاده از یک فایل پیکربندی که از طریق گزینه --config-file ارائه می‌شود نیز اضافه کرد. استفاده از این گزینه با تعیین database در خط فرمان مانعةالجمع است. برای توصیف تفصیلی قالب فایل پیکربندی، ovsdb(7) را مشاهده فرمایید.

این پیاده‌سازی OVSDB از مدل‌های سرویس پایگاه داده مستقل (standalone)، فعال-پشتیبان (active-backup)، بازپخش (relay) و خوشه‌ای (clustered)، و نیز تکثیر پایگاه داده پشتیبانی می‌کند. برای اطلاعات بیشتر بخش Service Models از ovsdb(7) را بررسی فرمایید.

در پایگاه‌های داده خوشه‌ای، زمانی که گزینه --detach استفاده می‌شود، ovsdb-server بدون انتظار برای پیوستن موفقیت‌آمیز سرور به خوشه (اگر فایل پایگاه داده تازه با ovsdb-tool join-cluster ایجاد شده باشد) یا اتصال به خوشه‌ای که قبلاً به آن پیوسته است، جدا (detach) می‌شود. از ovsdb-client wait (مراجعه به ovsdb-client(1)) استفاده کنید تا سرور با موفقیت به خوشه بپیوندد و متصل شود. همین موضوع در مورد پایگاه‌های داده relay نیز صدق می‌کند. می‌توان از همان دستورها برای انتظار جهت اتصال یک پایگاه داده relay به منبع رله (remote) استفاده کرد.

علاوه بر پایگاه‌های داده مشخص‌شده توسط کاربر، نگارش ۲٫۹ و جدیدتر ovsdb-server همواره میزبان یک پایگاه داده داخلی به نام _Server نیز هست. لطفاً برای مستندات مربوط به شمای (schema) این پایگاه داده، ovsdb-server(5) را ببینید.

روش remote را به‌عنوان روش اتصال مورد استفاده توسط ovsdb-server اضافه می‌کند. remote می‌تواند یک روش اتصال OVSDB فعال یا غیرفعال باشد، مانند pssl:6640، همان‌گونه که در ovsdb(7) توصیف شده است. شکل تکمیلی زیر نیز پشتیبانی می‌شود:
روش‌های اتصال تکمیلی را از column در تمام سطرهای table درون db می‌خواند. با تغییر محتوای column، برنامه ovsdb-server نیز متناسب با آن روش‌های اتصال را اضافه کرده یا حذف می‌کند.
اگر نوع column از نوع رشته (string) یا مجموعه‌ای از رشته‌ها باشد، در این صورت روش‌های اتصال مستقیماً از ستون خوانده می‌شوند. روش‌های اتصال در این ستون باید یکی از ساختارهای بیان‌شده در بالا را داشته باشند.
اگر نوع column از نوع شناسه یکتا (UUID) یا مجموعه‌ای از UUIDها باشد و به یک جدول ارجاع دهد، در این صورت هر UUID در جدول ارجاع‌داده‌شده جستجو می‌شود تا سطر مورد نظر به دست آید. ستون‌های زیر در سطر، در صورت وجود و داشتن نوع صحیح، یک روش اتصال را پیکربندی می‌کنند. هر ستون اضافی دیگری نادیده گرفته می‌شود.
روش اتصال، در یکی از اشکال بیان‌شده در بالا. این ستون الزامی است: اگر وجود نداشته باشد یا خالی باشد، هیچ روش اتصالی قابل پیکربندی نخواهد بود.
حداکثر مدت‌زمان انتظار بین تلاش‌های اتصال برحسب میلی‌ثانیه.
حداکثر مدت‌زمان بیکاری اتصال به کلاینت قبل از ارسال پیام سنجش عدم فعالیت (inactivity probe) برحسب میلی‌ثانیه.
در صورت مقدار true، فقط تراکنش‌های فقط‌خواندنی روی این اتصال مجاز هستند.
داشتن نوع دیگری برای column خطا محسوب می‌شود.
برای اتصال یا گوش فرادادن روی چند روش اتصال، از چندین گزینه --remote استفاده کنید.
به عنوان جایگزین، در صورتی که فایل پیکربندی از طریق گزینه --config-file ارائه شده باشد، می‌توان ریموت‌ها را در بخش "remotes" فایل پیکربندی تعیین کرد. گزینه‌های --config-file و --remote مانعةالجمع هستند.
یک فایل پیکربندی برای ovsdb-server مشخص می‌کند. این file می‌تواند حاوی روش‌های اتصال و پایگاه‌های داده مورد استفاده توسط سرور باشد. این file حاوی یک شیء JSON با دو عنصر اصلی است:
شیء JSON حاوی مجموعه‌ای از روش‌های اتصال در قالب زیر: "target": { "option": value, ... } که در آن target دارای همان قالبی است که برای remote در گزینه --remote بیان شد. مقدار option می‌تواند max-backoff (عدد صحیح)، inactivity-probe (عدد صحیح)، read-only (بولی)، role (رشته) یا dscp (عدد صحیح) با مقادیر مجاز مربوطه باشد. مفهوم این گزینه‌ها مشابه پیکربندی remote از طریق یک سطر پایگاه داده با گزینه --remote است.
شیء JSON که پایگاه‌های داده‌ای را که باید به ovsdb-server اضافه شوند در قالب زیر توصیف می‌کند: "name":{ "option": value, ... }. که در آن name نام فایل یک پایگاه داده ایجاد و مقداردهی‌شده از قبل، یا نام شمای پایگاه داده در مورد پایگاه‌های داده relay است. گزینه‌های موجود عبارتند از:
مدل سرویس این پایگاه داده را مشخص می‌کند. یکی از مقادیر: standalone، clustered، active-backup یا relay. این گزینه برای همه انواع، به جز standalone و clustered الزامی است. برای این پایگاه‌های داده، در صورتی که صریحاً مشخص نشده باشد، مدل سرویس از خود فایل استنباط خواهد شد. اگر service-model مشخص‌شده با فایل ارائه شده مطابقت نداشته باشد، ovsdb-server از افزودن پایگاه داده خودداری خواهد کرد.
روش اتصال به پایگاه داده فعال یا به منبع relay را مشخص می‌کند. این یک شیء JSON با دقیقاً یک عنصر در قالب مشابه عناصر "remotes" است، به جز اینکه گزینه‌های read-only و role قابل اعمال نیستند. مثال: "source": { "unix:db.sock": { "inactivity-probe": 10000, "max-backoff": 8000 } }
در صورت تنظیم روی true، برنامه ovsdb-server از این پایگاه داده به‌عنوان نسخه پشتیبان برای source مشخص‌شده استفاده خواهد کرد. در غیر این صورت به‌عنوان پایگاه داده فعال ارائه خواهد شد.
فهرستی از نام‌های جدول که باید از تکثیر در حالت پشتیبان مستثنی شوند، مثلاً "exclude-tables": [ "Table_One", "Table_Two" ].
محتوای ساده‌ترین فایل پیکربندی ممکن است به این شکل باشد: { "remotes": { "pssl:6640": {} }, "databases": { "conf.db": {} } }
نمونه‌هایی از فایل‌های پیکربندی برای مدل‌های سرویس گوناگون را می‌توان در ovsdb(7) یافت.
گزینه --config-file با گزینه --remote و همچنین با تعیین database در خط فرمان مانعةالجمع است. این گزینه همچنین با تمامی گزینه‌های فعال-پشتیبان و تمامی دستورات مدیریت زمان اجرا که بتوانند پیکربندی سرور را در تضاد با محتوای فایل تغییر دهند (یعنی تمامی دستوراتی که با ریموت‌ها و پایگاه‌های داده کار می‌کنند) ناسازگار و مانعةالجمع است. دستورات فقط‌خواندنی کماکان قابل استفاده هستند.
در صورت بروز تغییرات در file، کاربران باید دستور ovsdb-server/reload را با ابزار ovs-appctl(8) اجرا کنند تا تغییرات اعمال شوند.

به‌طور معمول ovsdb-server همیشه اجرا می‌شود، یا تا زمانی که به آن دستور خروج داده شود (بخش دستورات مدیریت زمان اجرا در زیر را ببینید). با این گزینه، ovsdb-server در عوض یک زیرفرآیند پوسته را برای اجرای command آغاز می‌کند. با پایان یافتن زیرفرآیند، ovsdb-server نیز با موفقیت خارج می‌شود. اگر زیرفرآیند به صورت عادی با کد خروج 0 پایان یابد، ovsdb-server نیز با کد خروج 0 خارج می‌شود؛ در غیر این صورت، با کد خروج 1 خارج خواهد شد.
این گزینه می‌تواند در مواردی مفید باشد که سرور پایگاه داده تنها برای اجرای یک دستور واحد مورد نیاز است، به عنوان مثال: ovsdb-server --remote=punix:socket --run='ovsdb-client dump unix:socket Open_vSwitch'

گزینه‌های زیر روی سیستم‌عامل‌های مبتنی بر POSIX معتبر هستند:

باعث ایجاد فایلی (به طور پیش‌فرض ovsdb-server.pid) می‌شود که نشان‌دهنده PID فرآیند در حال اجرا است. اگر آرگومان pidfile مشخص نشده باشد یا با / آغاز نشود، در مسیر /run/openvswitch ایجاد می‌گردد.
اگر --pidfile مشخص نشود، هیچ فایل شناسه فرآیندی (pidfile) ایجاد نمی‌شود.
به طور پیش‌فرض، هنگامی که --pidfile مشخص شده و فایل مشخص‌شده از قبل وجود داشته باشد و توسط فرآیندی در حال اجرا قفل شده باشد، ovsdb-server از شروع به کار خودداری می‌کند. برای بازنویسی فایل pidfile، گزینه --overwrite-pidfile را مشخص کنید.
هنگامی که --pidfile مشخص نشده باشد، این گزینه هیچ تأثیری ندارد.
اجرای ovsdb-server به عنوان یک فرآیند پس‌زمینه (دیمن). فرآیند فورک (fork) می‌شود و در فرآیند فرزند یک نشست جدید را آغاز کرده، توصیف‌کننده‌های استاندارد فایل را می‌بندد (که باعث غیرفعال شدن ثبت وقایع در کنسول می‌شود) و دایرکتوری کاری فعلی خود را به ریشه تغییر می‌دهد (مگر اینکه --no-chdir مشخص شده باشد). پس از تکمیل راه‌اندازی توسط فرزند، فرآیند والد خارج می‌شود. ovsdb-server تنها پس از شروع گوش دادن روی تمام ریموت‌های پیکربندی‌شده جدا (detach) می‌شود. در این نقطه، تمامی پایگاه‌های داده مستقل و فعال-پشتیبان آماده استفاده هستند. پایگاه‌های داده خوشه‌ای تنها پس از اتمام پیوستن به خوشه‌های خود آماده استفاده می‌شوند (که این ممکن است در اجراهای قبلی ovsdb-server رخ داده باشد).
یک فرآیند اضافی برای نظارت بر دیمن ovsdb-server ایجاد می‌کند. اگر دیمن به دلیل سیگنالی که نشان‌دهنده خطای برنامه‌نویسی است (SIGABRT، SIGALRM، SIGBUS، SIGFPE، SIGILL، SIGPIPE، SIGSEGV، SIGXCPU یا SIGXFSZ) متوقف شود، فرآیند ناظر یک نسخه جدید از آن را راه‌اندازی می‌کند. اگر دیمن به دلایل دیگری متوقف شود یا خارج گردد، فرآیند ناظر نیز خارج می‌شود.
این گزینه معمولاً همراه با --detach استفاده می‌شود، اما بدون آن نیز کار می‌کند.
به طور پیش‌فرض، هنگامی که --detach مشخص می‌شود، ovsdb-server پس از جدا شدن، دایرکتوری کاری فعلی خود را به دایرکتوری ریشه تغییر می‌دهد. در غیر این صورت، فراخوانی ovsdb-server از یک دایرکتوری تصادفی ممکن است مانع از این شود که مدیر سیستم بتواند سیستم‌فایل نگه‌دارنده آن دایرکتوری را unmount کند.
مشخص کردن --no-chdir این رفتار را لغو کرده و از تغییر دایرکتوری کاری فعلی توسط ovsdb-server جلوگیری می‌کند. این گزینه برای جمع‌آوری فایل‌های core مفید است، چرا که ایجاد core dump در دایرکتوری کاری معمول است و دایرکتوری ریشه جای مناسبی برای این کار نیست.
این گزینه زمانی که --detach مشخص نشده باشد هیچ تأثیری ندارد.
به طور پیش‌فرض دیمن تلاش می‌کند خود را محدود به کار با فایل‌های درون دایرکتوری‌های شناخته‌شده‌ای کند که در زمان ساخت تعیین شده‌اند. توصیه می‌شود به این رفتار پیش‌فرض پایبند باشید و از این گزینه استفاده نکنید مگر اینکه سیستم کنترل دسترسی دیگری برای محدود کردن دیمن به کار رفته باشد. توجه داشته باشید که بر خلاف کنترل‌های دسترسی کرنل (مانند DAC یا MAC)، خود‌محدودسازی (self-confinement) از طرف خود دیمن در فضای کاربری اعمال می‌شود و بنابراین نباید به عنوان یک راهبرد کامل مهار امنیتی تلقی شود، بلکه باید به عنوان یک لایه امنیتی تکمیلی دیده شود.
باعث می‌شود ovsdb-server با کاربر متفاوتی که در قالب "user:group" مشخص شده است اجرا شود، و در نتیجه اکثر امتیازات کاربر ریشه (root) سلب گردد. فرم‌های کوتاه "user" و ":group" نیز مجاز هستند که به ترتیب کاربر یا گروه جاری را فرض می‌کنند. فقط دیمن‌هایی که توسط کاربر ریشه راه‌اندازی می‌شوند این آرگومان را می‌پذیرند.
در لینوکس، پیش از سلب امتیازات ریشه، دسترسی‌های CAP_IPC_LOCK و CAP_NET_BIND_SERVICES به دیمن اعطا می‌شوند. دیمن‌هایی که با datapath تعامل دارند، مانند ovs-vswitchd، سه قابلیت دیگر یعنی CAP_NET_ADMIN، CAP_NET_BROADCAST و CAP_NET_RAW را نیز دریافت می‌کنند. این تغییر قابلیت‌ها حتی در صورتی که کاربر جدید root باشد نیز اعمال خواهد شد.


سطوح ثبت وقایع را تنظیم می‌کند. بدون درج هیچ spec، سطح لاگ برای هر ماژول و مقصد روی dbg تنظیم می‌شود. در غیر این صورت، spec فهرستی از کلمات جداشده با فاصله، کاما یا دونقطه است که از هر یک از دسته‌های زیر حداکثر یک مورد را شامل می‌شود:
  • یک نام ماژول معتبر، همان‌طور که توسط دستور vlog/list در ovs-appctl(8) نمایش داده می‌شود، که تغییر سطح لاگ را به ماژول مشخص‌شده محدود می‌کند.
  • syslog، console، یا file، به منظور محدود کردن تغییر سطح لاگ تنها به لاگ سیستم، کنسول یا یک فایل، به ترتیب. (اگر --detach مشخص شده باشد، ovsdb-server توصیف‌کننده‌های استاندارد فایل خود را می‌بندد، بنابراین ثبت لاگ در کنسول هیچ اثری نخواهد داشت.)
  • off، emer، err، warn، info یا dbg، برای کنترل سطح لاگ. پیام‌های با شدت مشخص‌شده یا بالاتر ثبت می‌شوند و پیام‌های با شدت پایین‌تر فیلتر می‌گردند. گزینه off تمامی پیام‌ها را فیلتر می‌کند. برای تعریف هر سطح لاگ، ovs-appctl(8) را ببینید.
بزرگی یا کوچکی حروف در spec اهمیتی ندارد.
صرف نظر از سطوح لاگ تعیین‌شده برای file، ثبت لاگ در فایل انجام نخواهد شد مگر اینکه --log-file نیز مشخص شده باشد (پایین را ببینید).
برای سازگاری با نگارش‌های قدیمی‌تر OVS، کلمه any پذیرفته می‌شود اما هیچ اثری ندارد.

حداکثر سطح جزئیات لاگ را تنظیم می‌کند که معادل --verbose=dbg است.

الگوی لاگ را برای destination روی pattern تنظیم می‌کند. برای شرح ساختار نحوی معتبر pattern به ovs-appctl(8) مراجعه کنید.

بخش تسهیلات RFC5424 (facility) پیام لاگ را تنظیم می‌کند. مقدار facility می‌تواند یکی از مقادیر kern، user، mail، daemon، auth، syslog، lpr، news، uucp، clock، ftp، ntp، audit، alert، clock2، local0، local1، local2، local3، local4، local5، local6 یا local7 باشد. اگر این گزینه مشخص نشود، daemon به عنوان پیش‌فرض برای لاگ سیستم محلی و local0 هنگام ارسال پیام به مقصد ارائه‌شده از طریق گزینه --syslog-target استفاده می‌شود.
ثبت لاگ در یک فایل را فعال می‌کند. اگر file مشخص شود، به عنوان نام دقیق فایل لاگ استفاده می‌شود. در صورت حذف file، نام پیش‌فرض فایل لاگ /var/log/openvswitch/ovsdb-server.log خواهد بود.
ارسال پیام‌های syslog به درگاه UDP مشخص‌شده با port در host، علاوه بر لاگ سیستم. مقدار host باید یک نشانی عددی IP باشد، نه نام میزبان.
روش ارسال پیام‌های syslog به دیمن syslog را مشخص می‌کند. اشکال زیر پشتیبانی می‌شوند:
  • libc، استفاده از تابع syslog() مربوط به libc. ایراد استفاده از این گزینه این است که libc قبل از ارسال پیام به دیمن syslog از طریق سوکت دامنه یونیکس /dev/log، یک پیشوند ثابت به هر پیام اضافه می‌کند.
  • unix:file، استفاده مستقیم از سوکت دامنه یونیکس. با این گزینه می‌توان فرمت پیام دلخواه را تعیین کرد. با این حال، نسخه rsyslogd 8.9 و نسخه‌های قدیمی‌تر در هر صورت از تابع تجزیه هاردکدشده استفاده می‌کنند که استفاده از سوکت دامنه یونیکس را محدود می‌کند. اگر می‌خواهید فرمت پیام دلخواه را با نسخه‌های قدیمی‌تر rsyslogd به کار ببرید، به جای آن از سوکت UDP به نشانی IP لوکال‌هاست استفاده کنید.
  • udp:ip:port، استفاده از سوکت UDP. با این روش می‌توان قالب پیام دلخواه را با نسخه‌های قدیمی‌تر rsyslogd نیز استفاده کرد. هنگام ارسال پیام‌های syslog روی سوکت UDP باید احتیاط‌های بیشتری در نظر گرفته شود؛ به عنوان مثال دیمن syslog باید طوری پیکربندی شود که به درگاه UDP مشخص‌شده گوش فرا دهد، قوانین تصادفی iptables ممکن است در ترافیک محلی syslog تداخل ایجاد کنند، و برخی ملاحظات امنیتی وجود دارند که در مورد سوکت‌های UDP صدق می‌کنند اما در مورد سوکت‌های دامنه یونیکس صدق نمی‌کنند.
  • null، نادیده گرفتن تمام پیام‌های ثبت‌شده در syslog.
مقدار پیش‌فرض از متغیر محیطی OVS_SYSLOG_METHOD گرفته می‌شود؛ اگر تنظیم نشده باشد، مقدار پیش‌فرض libc است.

این گزینه‌ها از مدل سرویس فعال-پشتیبان (active-backup) و تکثیر پایگاه داده در ovsdb-server پشتیبانی می‌کنند. این گزینه‌ها فقط برای پایگاه‌های داده‌ای با قالبی که برای پایگاه‌های داده مستقل و فعال-پشتیبان استفاده می‌شود (یعنی قالب پایگاه داده ایجادشده توسط ovsdb-tool create) اعمال می‌شوند. به طور پیش‌فرض، زمانی که پایگاه داده‌ای با این قالب ارائه می‌شود، ovsdb-server به عنوان یک سرور مستقل اجرا می‌گردد. این گزینه‌ها می‌توانند آن را برای استفاده فعال-پشتیبان پیکربندی کنند:

  • استفاده از --sync-from=server برای راه‌اندازی سرور در نقش پشتیبان (backup)، که داده‌ها را از server تکثیر می‌کند. هنگامی که ovsdb-server به عنوان یک سرور پشتیبان اجرا می‌شود، تمام تراکنش‌هایی را که بتوانند محتوای پایگاه داده را تغییر دهند (شامل دستورات قفل) رد می‌کند. همین قالب را می‌توان برای پیکربندی پایگاه داده محلی به عنوان کپی برابر اصل (replica) از server استفاده کرد.
  • استفاده از --sync-from=server --active برای راه‌اندازی سرور در نقش فعال (active)، اما آماده برای جابجایی به نقش پشتیبان که در آن داده‌ها را از server تکثیر خواهد کرد. هنگامی که ovsdb-server در حالت فعال اجرا می‌شود، تمام تراکنش‌ها (از جمله آن‌هایی که پایگاه داده را تغییر می‌دهند) را مجاز می‌داند.

در زمان اجرا، دستورات مدیریتی می‌توانند نقش سرور را تغییر داده و ویژگی‌های فعال-پشتیبان را مدیریت کنند. برای اطلاعات بیشتر، بخش دستورات فعال-پشتیبان در زیر را مشاهده فرمایید.

برنامه ovsdb-server را طوری تنظیم می‌کند که پایگاه‌های داده خود را با پایگاه‌های داده درون server همگام‌سازی کند، که باید یک روش اتصال فعال در یکی از قالب‌های مستندشده در ovsdb-client(1) باشد. هر تراکنشی که توسط server کامیت شود، به ovsdb-server تکثیر خواهد شد. این گزینه باعث می‌شود ovsdb-server به عنوان یک سرور پشتیبان شروع به کار کند؛ برای شروع به کار به عنوان یک سرور فعال، گزینه --active را اضافه کنید.
باعث می‌شود جداول مشخص‌شده از تکثیر مستثنی شوند.
به طور پیش‌فرض، گزینه --sync-from باعث می‌شود ovsdb-server به عنوان پشتیبان برای server شروع به کار کند. با این حال، با افزودن --active، برنامه ovsdb-server به عنوان سرور فعال آغاز به کار می‌نماید. از این گزینه استفاده کنید تا گزینه‌های همگام‌سازی با استفاده از گزینه‌های خط فرمان مشخص شوند، اما سرور به عنوان سرور فعال پیش‌فرض شروع شود. برای جابجایی سرور در حال اجرا به حالت پشتیبان، از ovs-appctl(1) برای اجرای دستور ovsdb-server/connect-active-ovsdb-server استفاده کنید.

این گزینه‌ها با --config-file مانعةالجمع هستند.

گزینه‌های توصیف‌شده در زیر برای پیکربندی زیرساخت کلید عمومی SSL، ساختار ویژه‌ای را برای دریافت پیکربندی خود از پایگاه داده می‌پذیرند. اگر به هر یک از این گزینه‌ها آرگومان db:db,table,column داده شود، در این صورت نام واقعی فایل از column مشخص‌شده در table درون پایگاه داده db خوانده می‌شود. ستون column باید از نوع رشته یا مجموعه‌ای از رشته‌ها باشد. اولین رشته غیرخالی در جدول به عنوان نام فایل در نظر گرفته می‌شود. (این بدان معناست که معمولاً باید حداکثر یک سطر در table وجود داشته باشد.)


یک فایل PEM حاوی کلید خصوصی مشخص می‌کند که به عنوان هویت ovsdb-server برای اتصالات خروجی SSL/TLS استفاده می‌شود.

یک فایل PEM حاوی گواهی مشخص می‌کند که نشان می‌دهد کلید خصوصی مشخص‌شده با -p یا --private-key قابل اعتماد است. این گواهی باید توسط مرجع صدور گواهی (CA) که طرف مقابل در اتصالات SSL/TLS برای اعتبارسنجی آن استفاده خواهد کرد، امضا شده باشد.

یک فایل PEM حاوی گواهی CA مشخص می‌کند که ovsdb-server باید برای اعتبارسنجی گواهی‌های ارائه‌شده توسط همتایان SSL/TLS از آن استفاده کند. (این ممکن است همان گواهی‌ای باشد که همتایان SSL/TLS برای تأیید گواهی مشخص‌شده در -c یا --certificate استفاده می‌کنند، یا بسته به طراحی PKI مورد استفاده متفاوت باشد.)

اعتبارسنجی گواهی‌های ارائه‌شده توسط همتایان SSL/TLS را غیرفعال می‌کند. این کار خطرات امنیتی ایجاد می‌کند، چرا که به این معنی است که نمی‌توان تأیید کرد که گواهی‌ها متعلق به میزبان‌های قابل اعتماد شناخته‌شده هستند یا خیر.
نام سرور را برای استفاده در نشانگر نام سرور (SNI) در TLS مشخص می‌کند. به طور پیش‌فرض، نام میزبان برگرفته از رشته اتصال برای SNI استفاده می‌شود. این گزینه امکان بازنویسی نام میزبان SNI را فراهم می‌کند، که هنگام اتصال از طریق پروکسی‌ها یا سرویس‌مش‌ها که در آن‌ها نقطه پایانی اتصال با نام سرور مورد نظر متفاوت است، کاربرد دارد.
هنگامی که cacert.pem وجود داشته باشد، این گزینه همان اثری را دارد که -C یا --ca-cert دارد. اگر وجود نداشته باشد، ovsdb-server در اولین اتصال SSL/TLS خود تلاش می‌کند گواهی CA را از طرف مقابل SSL/TLS دریافت کرده و آن را در فایل PEM نام‌گذاری‌شده ذخیره کند. در صورت موفقیت، بلافاصله اتصال را قطع کرده و دوباره وصل می‌شود، و از آن پس تمامی اتصالات SSL/TLS باید توسط گواهی امضاشده توسط گواهی CA به‌دست‌آمده احراز هویت شوند.
این گزینه اتصال SSL/TLS را در معرض حمله مرد میانی (man-in-the-middle) هنگام دریافت گواهی اولیه CA قرار می‌دهد، اما ممکن است برای راه‌اندازی اولیه (bootstrapping) مفید باشد.
این گزینه تنها در صورتی مفید است که طرف مقابل SSL/TLS گواهی CA خود را به عنوان بخشی از زنجیره گواهی SSL/TLS ارسال کند. پروتکل‌های SSL/TLS سرور را ملزم به ارسال گواهی CA نمی‌کنند.
این گزینه با -C و --ca-cert مانعةالجمع است.
یک فایل PEM را مشخص می‌کند که حاوی یک یا چند گواهی اضافی برای ارسال به همتایان SSL/TLS است. مقدار peer-cacert.pem باید گواهی CA مورد استفاده برای امضای گواهی اختصاصی ovsdb-server باشد، یعنی همان گواهی مشخص‌شده در -c یا --certificate. اگر گواهی ovsdb-server خود‌امضاشده (self-signed) باشد، آنگاه --certificate و --peer-ca-cert باید به یک فایل یکسان اشاره کنند.
این گزینه در عملکرد عادی کاربردی ندارد، زیرا همتای SSL/TLS برای اطمینان از هویت ovsdb-server باید از قبل گواهی CA را داشته باشد. با این حال، این روشی را برای یک نصب جدید فراهم می‌کند تا گواهی CA را در اولین اتصال SSL/TLS خود بارگذاری اولیه کند.

محدوده یا فهرستی جداشده با کاما یا فاصله از پروتکل‌های SSL/TLS را که ovsdb-server برای اتصالات SSL/TLS فعال خواهد کرد مشخص می‌کند. پروتکل‌های پشتیبانی‌شده (protocols) شامل TLSv1.2 و TLSv1.3 هستند. محدوده‌ها را می‌توان به صورت دو نام پروتکل جداشده با یک خط تیره، یا به صورت یک نام پروتکل همراه با علامت مثبت ارائه کرد. به عنوان مثال، از TLSv1.2-TLSv1.3 برای مجاز دانستن TLSv1.2 و TLSv1.3 استفاده کنید. برای مجاز دانستن TLSv1.2 و هر پروتکل جدیدتر بعدی از TLSv1.2+ استفاده کنید. این گزینه فهرستی از پروتکل‌ها یا دقیقاً یک محدوده را می‌پذیرد. استفاده از محدوده روش ترجیحی برای تعیین پروتکل‌ها است و این گزینه همیشه طوری عمل می‌کند که گویی محدوده بین حداقل و حداکثر نسخه مشخص‌شده ارائه شده است، یعنی اگر این گزینه روی TLSv1.X,TLSv1.(X+2) تنظیم شود، TLSv1.(X+1) نیز فعال خواهد شد گویا که یک محدوده بوده است. صرف نظر از ترتیب، بالاترین پروتکل پشتیبانی‌شده توسط هر دو طرف هنگام برقراری اتصال انتخاب خواهد شد. مقدار پیش‌فرض در صورت حذف این گزینه TLSv1.2 یا جدیدتر است.
الگوریتم‌های رمزنگاری (ciphers) را در قالب رشته سایفر OpenSSL مشخص می‌کند که ovsdb-server برای اتصالات SSL/TLS با TLSv1.2 پشتیبانی خواهد کرد. مقدار پیش‌فرض در صورت حذف این گزینه DEFAULT:@SECLEVEL=2 است.
مجموعه سایفرها (ciphersuites) را در قالب رشته سایفرسوئیت OpenSSL مشخص می‌کند که ovsdb-server برای اتصالات SSL/TLS با TLSv1.3 و بالاتر از آن پشتیبانی خواهد کرد. در صورت حذف این گزینه، مقدار پیش‌فرض OpenSSL استفاده خواهد شد.

نام سوکت کنترلی را تنظیم می‌کند که ovsdb-server روی آن به دستورات مدیریت زمان اجرا گوش می‌دهد (بخش دستورات مدیریت زمان اجرا را در زیر ببینید). اگر socket با / آغاز نشود، نسبت به /run/openvswitch تفسیر می‌گردد. اگر --unixctl اصلاً استفاده نشود، سوکت پیش‌فرض /run/openvswitch/ovsdb-server.pid.ctl است، که در آن pid شناسه فرآیند ovsdb-server است.
مشخص کردن مقدار none برای socket قابلیت سوکت کنترلی را غیرفعال می‌کند.
فرآیند را در حالت "ضبط" (recording) قرار می‌دهد که در آن تمام اتصالات، داده‌های جریان‌ها (سوکت‌های دامنه یونیکس و شبکه) و سایر بخش‌های ضروری را ضبط می‌کند تا بعداً بتوان آن‌ها را بازپخش کرد. داده‌های ضبط‌شده در فایل‌های بازپخش درون directory مشخص‌شده ذخیره می‌شوند. اگر directory با / آغاز نشود، نسبت به /run/openvswitch تفسیر می‌گردد. اگر directory مشخص نشود، از /run/openvswitch استفاده خواهد شد.
فرآیند را در حالت "بازپخش" (replay) قرار می‌دهد که در آن اطلاعات مربوط به اتصالات، داده‌های جریان‌ها (سوکت‌های دامنه یونیکس و شبکه) و سایر بخش‌های لازم را به جای استفاده از سوکت‌های واقعی، مستقیماً از فایل‌های بازپخش می‌خواند. فایل‌های بازپخش از directory استفاده خواهند شد. اگر directory با / آغاز نشود، نسبت به /run/openvswitch تفسیر می‌شود. اگر directory مشخص نشود، از /run/openvswitch استفاده خواهد شد.

چاپ پیام راهنمای مختصر در کنسول.

چاپ اطلاعات نسخه در کنسول.

ابزار ovs-appctl(8) می‌تواند دستوراتی را به یک فرآیند در حال اجرای ovsdb-server ارسال کند. دستورات پشتیبانی‌شده فعلی در زیر شرح داده شده‌اند.

این دستورات مختص ovsdb-server هستند.

باعث خاتمه مرتب و بی‌خطر (graceful) برنامه ovsdb-server می‌شود.
پایگاه داده db را درجا فشرده‌سازی (compact) می‌کند. اگر db مشخص نشده باشد، تمام پایگاه‌های داده را درجا فشرده می‌کند. همچنین زمانی که یک تراکنش ثبت می‌شود، اگر حجم پایگاه داده بیش از ۲ برابر اندازه فشرده‌شده قبلی آن باشد (و حداقل ۱۰ مگابایت)، به طور خودکار فشرده‌سازی انجام می‌شود، مشروط بر اینکه حداقل ۱۰۰ کامیت اضافه شده باشد یا ۱۰ دقیقه از آخرین فشرده‌سازی گذشته باشد. همچنین اگر ۱۰۰ کامیت بدون در نظر گرفتن حجم آن اضافه شده باشد، پس از ۲۴ ساعت از آخرین فشرده‌سازی، به طور خودکار فشرده خواهد شد.
اگر این گزینه روی on باشد، ovsdb-server پس از هر فشرده‌سازی موفقیت‌آمیز پایگاه داده تلاش می‌کند تمام حافظه هیپ (heap) بدون استفاده را به سیستم بازگرداند تا مصرف حافظه فرآیند کاهش یابد. پیش‌فرض off است.
باعث می‌شود ovsdb-server تمام اتصالات JSON-RPC به کلاینت‌های پایگاه داده را قطع کرده و مجدداً متصل شود.
این دستور ممکن است برای اشکال‌زدایی مشکلات مربوط به کلاینت‌های پایگاه داده مفید باشد.
یک ریموت اضافه می‌کند، گویی که --remote=remote در خط فرمان ovsdb-server مشخص شده باشد. (اگر remote از قبل یک ریموت باشد، این دستور بدون تغییر در پیکربندی با موفقیت انجام می‌شود.)
با گزینه --config-file مانعةالجمع است.
ریموت مشخص‌شده (remote) را از پیکربندی حذف می‌کند، و اگر remote به عنوان ریموت پیکربندی نشده باشد با خطا مواجه می‌شود. این دستور تنها با ریموت‌هایی کار می‌کند که در --remote یا ovsdb-server/add-remote نام‌گذاری شده باشند؛ یعنی ریموت‌هایی را که به طور غیرمستقیم از طریق پیکربندی یک ریموت db:db,table,column از پایگاه داده خوانده شده‌اند حذف نخواهد کرد. (شما می‌توانید یک منبع پایگاه داده را با ovsdb-server/remove-remote db:db,table,column حذف کنید، اما نه ریموت‌های مجزایی را که به طور غیرمستقیم از طریق پایگاه داده پیدا شده‌اند.)
با گزینه --config-file مانعةالجمع است.
فهرستی از ریموت‌های پیکربندی‌شده فعلی را که در --remote یا ovsdb-server/add-remote نام برده شده‌اند خروجی می‌دهد؛ یعنی ریموت‌هایی را که به طور غیرمستقیم از طریق پیکربندی ریموت db:db,table,column از پایگاه داده خوانده شده‌اند فهرست نمی‌کند.
پایگاه داده database را به ovsdb-server در حال اجرا اضافه می‌کند. مقدار database می‌تواند یک فایل پایگاه داده یا توصیف relay در قالب زیر باشد: relay:schema_name:remote. فایل پایگاه داده باید از قبل با استفاده از ابزارهایی مانند ovsdb-tool create ایجاد و مقداردهی اولیه شده باشد.
با گزینه --config-file مانعةالجمع است.
پایگاه داده database را از ovsdb-server در حال اجرا حذف می‌کند. مقدار database باید نام پایگاه داده‌ای باشد که توسط ovsdb-server/list-dbs فهرست شده است.
اگر ریموتی پیکربندی شده باشد که به database مشخص‌شده اشاره کند (مثلاً --remote=db:database,... در خط فرمان)، تا زمانی که پایگاه داده دیگری با همان نام مجدداً اضافه شود (با ovsdb-server/add-db)، غیرفعال خواهد شد.
هر یک از گزینه‌های زیرساخت کلید عمومی که از طریق این پایگاه داده مشخص شده باشند (مانند --private-key=db:database,... در خط فرمان) تا زمانی که پایگاه داده دیگری با همان نام دوباره اضافه شود (با ovsdb-server/add-db) غیرفعال خواهند بود.
با گزینه --config-file مانعةالجمع است.
فهرستی از پایگاه‌های داده‌ای را که در حال حاضر از طریق خط فرمان یا دستور ovsdb-server/add-db اضافه شده‌اند خروجی می‌دهد.
ثبت لاگ تمام عملیات اجراشده روی پایگاه داده و جدول مشخص‌شده را فعال یا غیرفعال می‌کند. لاگ‌ها در سطح INFO تولید می‌شوند و دارای محدودیت نرخ (rate limit) هستند.
وضعیت ثبت لاگ را برای تمام پایگاه‌های داده و جداول پیکربندی‌شده فعلی نمایش می‌دهد.

این دستورات نقش ovsdb-server را درون یک جفت سرور فعال-پشتیبان استعلام و به‌روزرسانی می‌کنند. برای اطلاعات بیشتر، بخش گزینه‌های فعال-پشتیبان در بالا و بخش Active-Backup Database Service Model در ovsdb(7) را مشاهده فرمایید.

تمامی دستورات فعال-پشتیبان که وضعیت ovsdb-server را تغییر می‌دهند با گزینه --config-file مانعةالجمع هستند.

سرور فعال server را که ovsdb-server از طریق ovsdb-server/connect-active-ovsdb-server به آن متصل می‌شود تنظیم می‌کند. این دستور گزینه خط فرمان --sync-from را بازنویسی می‌کند.
سرور فعالی را که ovsdb-server در حال حاضر پایگاه‌های داده خود را با آن همگام‌سازی می‌کند دریافت می‌نماید.
سرور را به نقش پشتیبان جابجا می‌کند. سرور شروع به همگام‌سازی پایگاه‌های داده خود با سرور فعال مشخص‌شده توسط ovsdb-server/set-active-ovsdb-server (یا گزینه خط فرمان --sync-from) می‌کند و تمام اتصالات کلاینت موجود را می‌بندد، که مستلزم اتصال مجدد کلاینت‌ها است.
سرور را به نقش فعال جابجا می‌کند. سرور همگام‌سازی پایگاه‌های داده خود با سرور فعال را متوقف کرده و تمامی اتصالات کلاینت موجود را می‌بندد، که مستلزم اتصال مجدد کلاینت‌ها است.
فاصله سنجش اتصال (inactivity probe interval برحسب میلی‌ثانیه) را برای اتصال به server فعال تنظیم می‌کند.
جداول (table) درون db را که از همگام‌سازی مستثنی خواهند شد تعیین می‌کند. این دستور گزینه خط فرمان --sync-exclude-tables را بازنویسی می‌کند.
جداولی را که در حال حاضر از همگام‌سازی مستثنی هستند نمایش می‌دهد.
خلاصه‌ای از اطلاعات زمان اجرای تکثیر را چاپ می‌کند. اطلاعات وضعیت (state) همواره ارائه می‌شود و نشان می‌دهد که آیا سرور در حالت active یا backup اجرا می‌شود. برای تمام پایگاه‌های داده با مدل سرویس فعال-پشتیبان، وضعیت اتصال تکثیر که می‌تواند یکی از مقادیر connecting، replicating یا error باشد نمایش داده می‌شود. هنگامی که اتصال در وضعیت replicating است، خروجی بیشتر جداولی را که در حال حاضر از تکثیر مستثنی شده‌اند نشان می‌دهد.

این دستورات از مدل سرویس خوشه‌بندی‌شده (clustered) در ovsdb-server پشتیبانی می‌کنند. آن‌ها تنها برای پایگاه‌های داده‌ای در قالبی که برای پایگاه‌های داده خوشه‌ای استفاده می‌شود اعمال می‌گردند؛ یعنی قالب پایگاه داده ایجادشده توسط ovsdb-tool create-cluster و ovsdb-tool join-cluster.

شناسه خوشه (cluster ID) را برای db چاپ می‌کند، که یک UUID برای شناسایی خوشه است. اگر db یک پایگاه داده تازه ایجادشده توسط ovsdb-tool cluster-join باشد که هنوز با موفقیت به خوشه خود نپیوسته است، و گزینه --cid در خط فرمان cluster-join مشخص نشده باشد، این دستور یک خطا گزارش خواهد کرد زیرا شناسه خوشه هنوز مشخص نیست.
شناسه سرور (server ID) را برای db چاپ می‌کند، که یک UUID برای شناسایی این سرور درون خوشه است.
وضعیت این سرور درون خوشه و وضعیت اتصالات آن به سایر سرورهای درون خوشه را چاپ می‌کند.
این دستور خروج مرتب و ایمن سرور از خوشه خود را آغاز می‌کند. حداقل یک سرور باید در خوشه باقی بماند و وضعیت خوشه باید سالم باشد؛ به این معنی که بیش از نیمی از سرورهای خوشه باید فعال باشند.
هنگامی که سرور با موفقیت از خوشه خارج می‌شود، ارائه خدمت برای db را متوقف می‌کند، گویی دستور ovsdb-server/remove-db db اجرا شده باشد.
از دستور ovsdb-client wait (مراجعه به ovsdb-client(1)) برای انتظار تا زمانی که سرور از خوشه خارج شود استفاده کنید.
هنگامی که یک سرور از یک خوشه خارج می‌شود، هرگز نمی‌تواند دوباره به آن بپیوندد. در عوض، باید یک سرور جدید بسازید و آن را به خوشه ملحق کنید.
توجه داشته باشید که حذف سرور از خوشه اندازه کل خوشه را تغییر می‌دهد. به عنوان مثال اگر دو سرور را از یک خوشه سه‌سروره حذف کنید، "خوشه" به یک سرور منفرد فعال تبدیل می‌شود. این کار منجر به ایجاد یک خوشه سه‌سروره فاقد حد نصاب (quorum) نمی‌شود.
خروج ایمن server را از خوشه db آغاز می‌کند، مشابه cluster/leave، با این تفاوت که می‌تواند هر سروری را حذف کند، نه فقط این سرور را.
مقدار server می‌تواند شناسه سرور باشد، همان‌طور که توسط cluster/sid چاپ می‌شود، یا آدرس شبکه محلی سرور همان‌گونه که به دستور create-cluster یا join-cluster ابزار ovsdb-tool پاس داده شده است. از cluster/status برای دیدن فهرستی از اعضای خوشه استفاده کنید.
مقدار پایه تایم‌اوت انتخاب رهبر در خوشه را برحسب میلی‌ثانیه تغییر می‌دهد.
اگر در این مدت‌زمان به علاوه یک زمان تصادفی حداکثر ۱ ثانیه‌ای هیچ پیام ضربان قلبی (heartbeat) از رهبر دریافت نشود، انتخاب رهبر توسط یک پیرو (follower) آغاز خواهد شد.
مقدار پیش‌فرض 1000 است، مگر اینکه با این دستور تغییر یابد. از این دستور می‌توان در صورت نیاز برای تنظیم مقدار متناسب با بار کاری مورد انتظار و زمان پاسخ‌گویی سرورها استفاده کرد.
این دستور باید روی رهبر اجرا شود. این دستور تغییرات را در خوشه آغاز می‌کند. برای بررسی اعمال شدن تغییر (commit شدن)، از cluster/status برای نمایش تنظیمات فعلی استفاده کنید. پس از کامیت شدن، تغییرات در راه‌اندازی‌های مجدد سرور نیز حفظ خواهند شد.
محدودیت‌های انباشتگی (backlog) را برای اتصالات RAFT مربوط به db روی حداکثر n_msgs پیام یا n_bytes بایت تنظیم می‌کند. اگر انباشتگی در یکی از اتصالات به حد مجاز برسد، اتصال قطع می‌شود (و مجدداً برقرار می‌گردد). مقادیر تنها در صورتی بررسی می‌شوند که انباشتگی شامل بیش از ۵۰ پیام باشد.

این دستورات تنظیمات ثبت وقایع (لاگینگ) ovsdb-server را مدیریت می‌کنند.

سطوح ثبت وقایع را تنظیم می‌کند. بدون درج هیچ spec، سطح لاگ برای هر ماژول و مقصد روی dbg تنظیم می‌شود. در غیر این صورت، spec فهرستی از کلمات جداشده با فاصله، کاما یا دونقطه است که از هر یک از دسته‌های زیر حداکثر یک مورد را شامل می‌شود:
  • یک نام ماژول معتبر، همان‌طور که توسط دستور vlog/list در ovs-appctl(8) نمایش داده می‌شود، که تغییر سطح لاگ را به ماژول مشخص‌شده محدود می‌کند.
  • syslog، console، یا file، به منظور محدود کردن تغییر سطح لاگ تنها به لاگ سیستم، کنسول یا یک فایل، به ترتیب.
  • off، emer، err، warn، info یا dbg، برای کنترل سطح لاگ. پیام‌های با شدت مشخص‌شده یا بالاتر ثبت می‌شوند و پیام‌های با شدت پایین‌تر فیلتر می‌گردند. گزینه off تمامی پیام‌ها را فیلتر می‌کند. برای تعاریف سطوح لاگ، ovs-appctl(8) را ببینید.
بزرگی یا کوچکی حروف در spec اهمیت ندارد.
صرف نظر از سطوح لاگ تعیین‌شده برای file، ثبت لاگ در فایل انجام نخواهد شد مگر اینکه ovsdb-server با گزینه --log-file فراخوانی شده باشد.
برای سازگاری با نگارش‌های قدیمی‌تر OVS، کلمه any پذیرفته می‌شود اما هیچ اثری ندارد.

الگوی لاگ را برای destination روی pattern تنظیم می‌کند. برای شرح ساختار نحوی معتبر pattern به ovs-appctl(8) مراجعه فرمایید.
ماژول‌های لاگینگ پشتیبانی‌شده و سطوح فعلی آن‌ها را فهرست می‌کند.
الگوهای لاگینگ مورد استفاده برای هر مقصد را فهرست می‌کند.
باعث می‌شود ovsdb-server فایل لاگ خود را در صورت باز بودن ببندد. (برای باز کردن مجدد آن بعداً از vlog/reopen استفاده کنید.)
باعث می‌شود ovsdb-server فایل لاگ خود را در صورت باز بودن ببندد و سپس مجدداً باز کند. (این کار پس از چرخش فایل‌های لاگ (log rotate) برای استفاده از فایل لاگ جدید مفید است.)
این دستور هیچ اثری ندارد مگر اینکه ovsdb-server با گزینه --log-file اجرا شده باشد.

به طور پیش‌فرض، ovsdb-server نرخی را که در آن پیام‌های خاصی می‌توانند ثبت شوند محدود می‌کند. هنگامی که یک پیام مکررتر از حد مجاز ظاهر شود، مهار (suppress) می‌شود. این کار فضای دیسک را ذخیره می‌کند، خواندن لاگ‌ها را آسان‌تر می‌سازد و سرعت اجرا را افزایش می‌دهد، اما گاهی اوقات عیب‌یابی نیازمند جزئیات بیشتر است. بنابراین، دستور vlog/disable-rate-limit امکان غیرفعال کردن محدودیت‌های نرخ را در سطح یک ماژول لاگ مجزا فراهم می‌آورد. یک یا چند نام ماژول را همان‌گونه که با دستور vlog/list نمایش داده می‌شوند مشخص کنید. عدم تعیین هیچ نام ماژولی یا استفاده از کلیدواژه any محدودیت‌های نرخ را برای همه ماژول‌های لاگ غیرفعال می‌کند.
دستور vlog/enable-rate-limit که ساختار نحوی آن مشابه vlog/disable-rate-limit است، می‌تواند برای فعال‌سازی مجدد محدودیت نرخی که قبلاً غیرفعال شده بود استفاده شود.

این دستورات میزان مصرف حافظه را گزارش می‌دهند.

برخی آمار پایه درباره مصرف حافظه ovsdb-server را نمایش می‌دهد. برنامه ovsdb-server نیز این اطلاعات را اندکی پس از راه‌اندازی و به صورت دوره‌ای با افزایش مصرف حافظه ثبت می‌کند.

این دستورات «شمارنده‌های پوشش» (coverage counters) برنامه ovsdb-server را مدیریت می‌کنند که تعداد دفعات رخداد رویدادهای خاص در زمان اجرای دیمن را می‌شمارند. علاوه بر این دستورات، زمانی که ovsdb-server تشخیص دهد حلقه اصلی دیمن زمان بسیار طولانی غیرمعمولی برای اجرا نیاز داشته است، مقادیر شمارنده پوشش را به طور خودکار در سطح INFO ثبت می‌کند.

شمارنده‌های پوشش عمدتاً برای تحلیل کارایی و اشکال‌زدایی مفید هستند.

نرخ‌های میانگین در ثانیه برای چند ثانیه گذشته، دقیقه گذشته و ساعت گذشته، و همچنین شمارش کلی تمامی شمارنده‌های پوشش را نمایش می‌دهد.
شمارش کل را برای counter پوشش مشخص‌شده نمایش می‌دهد.

در نسخه‌های Open vSwitch پیش از نسخه ۲٫۴، هنگامی که ovsdb-server پاسخ‌های خطای JSON-RPC را به برخی درخواست‌ها ارسال می‌کرد، آن‌ها را به اشتباه به گونه‌ای فرمول‌بندی می‌کرد که result و error جابجا شده بودند، به طوری که پاسخ به جای خطا، نشان‌دهنده موفقیت (با یک نتیجه بی‌معنی) به نظر می‌رسید. درخواست‌هایی که از این مشکل رنج می‌بردند عبارت بودند از:


تنها در صورتی که درخواست نام یک پایگاه داده ناموجود را مشخص می‌کرد.


در تمام موارد خطا.

از میان این موارد، تنها خطایی که یک برنامه با نگارش مناسب در عمل احتمالاً با آن مواجه می‌شود، دستور monitor روی جداول یا ستون‌هایی است که وجود ندارند، در شرایطی که برنامه ارتقا یافته اما شمای پایگاه داده قدیمی کماکان به طور موقت در حال استفاده است. برای مدیریت مناسب این وضعیت، توصیه می‌کنیم که کلاینت‌ها پاسخ monitor دارای یک result را که حاوی جفت کلید-مقدار error است به عنوان خطا در نظر بگیرند (با این فرض که پایگاه داده تحت نظارت شامل جدولی به نام error نیست).

ovsdb(7), ovsdb-tool(1), ovsdb-server(5), ovsdb-server(7).

4.0.0 Open vSwitch