group.of.nepali.translators team mailing list archive

[ChristianEhrhardt <1738864@xxxxxxxxxxxxxxxxxx>]

You'd add [2] and always take packages from there non selectively.
So normal add-apt-repository and after that just update/upgrade as usual according to your maintenance policies.

I'd say that while libvirt/qemu can break things I'd have very rarely seen those to manifest as system instabilities - so I'd assume other changes would have caused this.
In general I'd recommend to do the change on a few systems only to begin with and see if they behave up to your expectation for a while.
Also maybe do not change the week before Christmas, but more in January :-)

On the SRU I think we agree that we will not change the version as in
Xenial for the reasons outlined before - thanks for your understanding.
I'm marking the bug task accordingly.

I'll stay subscribed here to help you with the general discussion.

** Changed in: libvirt (Ubuntu Xenial)
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1738864

Title:
  libvirt updates all iSCSI targets from host each time a pool is
  started

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Trusty:
  Won't Fix
Status in libvirt source package in Xenial:
  Won't Fix

Bug description:
  Hello everyone, I'm a little confused about the behavior of libvirt in
  Ubuntu 16.04.3.

  We have up to 140 iSCSI targets on a single storage host, and all of
  these are made available to our VM hosts. If I stop one of the iSCSI
  pools through virsh ("virsh pool-destroy iscsipool1") and start it
  back up again while running libvirt in debug, I see that it runs a
  discovery and proceeds to go through and update every single target
  available on that host -- even targets that we do not use, instead of
  simply connecting to that target.

  This turns a <1 second process into a minimum of 30 seconds, and I
  just ran it with the stopwatch and clocked it at 64 seconds. So if we
  are doing maintenance on these hosts and go for a reboot, it takes
  90-120+ minutes to finish auto starting all of the iSCSI pools. And of
  course, during this period of time, the server is completely worthless
  as a VM host. Libvirt is just stuck until it finishes connecting
  everything. Manually connecting to the targets using iscsiadm without
  doing all the same hubbub that libvirt is doing connects these targets
  immediately, as I would expect from libvirt.

  And for each of the 140 iSCSI targets, it goes through and runs an
  iscsiadm sendtargets and then updates every single target before
  finally connecting the respective pool.

  We also noticed that libvirt in Ubuntu 17.10 does not have this
  behavior. Well maybe it does, but it connects the iSCSI targets
  immediately. It is a much different process than Ubuntu 16.04.3.

  Any help would be greatly appreciated. Thank you so much.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1738864/+subscriptions