Вопросы Теги

VMware заставляет мой хост Linux терять сетевое соединение?

Эти два никоим образом не эквивалентны. Отключение журнала делает точно что: выключает журналирование. Установка режима журнала к обратной записи, с другой стороны, выключает определенные гарантии о данных файла при уверении непротиворечивости метаданных посредством журналирования.

data=writeback опция в man(8) mount говорит:

Упорядочивание данных не сохраняется - данные могут быть записаны в основную файловую систему после того, как ее метаданные посвятили себя журналу. Это, как известно по слухам, является самым высоким - опция пропускной способности. Это гарантирует внутреннюю целостность файловой системы, однако это может позволить старым данным появляться в файлах после восстановления журнала и катастрофического отказа.

Установка data=writeback может иметь смысл при некоторых обстоятельствах, когда пропускная способность более важна, чем содержание файла. Журналирование только метаданных является компромиссом, который много файловых систем делают, но не отключают журнал полностью, если у Вас нет очень серьезного основания.

1
14.06.2013, 02:52
2 ответа

Ответ на мой вопрос был "да" - VMware поливал из шланга мою возможность соединения сети узла, потому что это было на том же 192.168.x.x сеть. Это было ведущим к неправильной маршрутизации. Я удалил VMware, говоря этому удалить все существующие конфигурации (после того, как резервное копирование моих гостевых изображений) и переустановленный. После переустановки моя сеть узла продолжала функционировать, и VMware работал правильно (т.е., я мог загрузить гостей и получить доступ к Интернету, и т.д.). Таким образом, все хорошо теперь.

Вот мой текущий вывод ifconfig:

eth0      Link encap:Ethernet  HWaddr 00:90:f5:d8:8e:6a 
          inet addr:192.168.254.27  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::290:f5ff:fed8:8e6a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:141969 errors:0 dropped:0 overruns:0 frame:0
          TX packets:76218 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:204301662 (204.3 MB)  TX bytes:6255750 (6.2 MB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1065 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:154990 (154.9 KB)  TX bytes:154990 (154.9 KB)

vmnet1    Link encap:Ethernet  HWaddr 00:50:56:c0:00:01 
          inet addr:172.16.145.1  Bcast:172.16.145.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vmnet8    Link encap:Ethernet  HWaddr 00:50:56:c0:00:08 
          inet addr:192.168.17.1  Bcast:192.168.17.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Обратите внимание, что vmnet1 находится в другой сети (172.16), тогда как vmnet8 находится в 192,168 сетях - противоположность того, что я имел, когда я потерял возможность соединения сети узла.

[Обновление]: посмотрите Редактирование @slm № 2 для дополнительных деталей, который объясняет больше из этого.

0
27.01.2020, 23:39

Это кажется нечетным, что Ваше устройство Ethernet является eth1 и не eth0. Вы вспоминаете, было ли Ваше устройство Ethernet eth0 ранее? Я подозревал бы, что то, когда Вы обновили что-то, произошло с Вашими правилами udev.

Принятие Вас имеет только единственный Ethernet NIC в Вашей системе, проверяет этот файл и удостоверяется, что существует только однократный въезд в нем:

# /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# net device () (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="54:52:00:ff:ff:dd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

У Вас должен только быть сингл SUBSYSTEM строка в конце этого файла. Если Вы будете иметь больше, то необходимо будет удалить любые дополнительные строки и удостовериться та, которая остается, корректно с точки зрения MAC-адреса, который она указывает.

РЕДАКТИРОВАНИЕ № 1

На основе обратной связи OP на его файле: /etc/udev/rules.d/70-persistent-net.rules, Я внес бы следующие изменения:

$ cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.2 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:f5:d8:8e:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

РЕДАКТИРОВАНИЕ № 2

Вы пытались переустановить его уже? Vmnet1, предполагают, чтобы быть локальной сетью только для VMs и хоста, на котором они работают. Я подозреваю то, что продолжается, то, что IP-адрес, который привыкает Вашим vmnet1, также используется другой системой на Вашей LAN, вызывающей конфликт. Смотрите на это учебное руководство, названное: Учебное руководство по Интерфейсам VMware.

Конкретно проверьте раздел по Хосту только Сетевое соединение. Эта схема из того учебного руководства показывает подобную установку тому, о чем Вы сообщаете.

                      ss of network

Таким образом, проблема, казалось бы, была бы, что Ваш исходный eth1 IP-адрес (192.168.254.27) устройства и IP-адрес / подсеть, используемая vmnet (192.168.254.1), конфликтовали, потому что маршрутизация, локальная для Вашего хоста, вероятно, получала настройки с конфликтующей маршрутизацией.

Были, вероятно, записи, которые направляли трафик, предназначенный для конкретного IP-адреса к нескольким местоположениям, который не позволяется.

2
27.01.2020, 23:39
  • 1
    Посмотрите мою обновленную информацию в разделе вопроса. У меня есть записи и для eth0 и для eth1 (и wlan0 и wlan1). Действительно ли это - проблема, чтобы иметь eth1, отображенный на моем NIC? Если так, как делают меня карта eth0 к нему вместо этого? –  quux00 14.06.2013, 01:08
  • 2
    Посмотрите мои редактирования, я полагаю, что можно внести те изменения и перезапустить сеть. Необходимо видеть, что eth0 должен подойти и получить IP-адрес. –  slm♦ 14.06.2013, 06:48
  • 3
    , который я внес изменением и оно действительно изменяло мою систему для использования eth0, а не eth1, таким образом, это хорошо и благодарит за это. Однако это не решило проблему. Только после того, как я удалил VMware Player, была моя восстановленная возможность соединения сети узла, таким образом, случалось так, что конфликт, поскольку я первоначально подозревал. –  quux00 15.06.2013, 04:58
  • 4
    @midpeter444 - довольный Вы решили свой вопрос. Я обновил свой ответ с большим количеством деталей. Если Вы хотите читать больше на сетях VMware, я включал ссылку на хорошее учебное руководство на них. –  slm♦ 15.06.2013, 05:45

Теги

Похожие вопросы