[Bug 1393923] Re: postfix (2.11.0-1) does not LDAP table lookup since libp11-kit0 (0.20.2-2ubuntu2)
Over a year later this problem still exists. It is impossible to run a Postfix server that does (SSL/TLS secured) LDAP lookups on Ubuntu 14.04.3. I wonder how is this not affecting more people? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to postfix in Ubuntu. https://bugs.launchpad.net/bugs/1393923 Title: postfix (2.11.0-1) does not LDAP table lookup since libp11-kit0 (0.20.2-2ubuntu2) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1393923/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1414684] Re: bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail)
FWIW, I am content with the updated USN and agree with Won't Fix. Just wanted to raise the issue here in case I am not the only one bitten by this change. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bsd-mailx in Ubuntu. https://bugs.launchpad.net/bugs/1414684 Title: bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bsd-mailx/+bug/1414684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1414684] Re: bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail)
Bug against Bootmail is here: https://bugs.launchpad.net/ubuntu/+source/bootmail/+bug/1414696 What do you suggest instead? I don't really have a suggestion and I am not disputing that this change was necessary. But the USN description doesn't even mention that specifying sendmail options after -- is no longer supported. After some back and forth (and seriously doubting my own sanity) I inferred that fact from the changelog which mentions a 83-nosendmail.patch. I just wish the USN advertised and documented this change and its full impact better. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bsd-mailx in Ubuntu. https://bugs.launchpad.net/bugs/1414684 Title: bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bsd-mailx/+bug/1414684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1414684] [NEW] bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail)
Public bug reported: The security update of bsd-mailx (8.1.2-0.2006cvs-1ubuntu0.1 on Ubuntu 12.04) removes bsd-mailx's support for specifying sendmail options after -- on the commandline. This breaks any script that supplies classic sendmail options like -F or -f on the mail commandline. A prominent example is Bootmail, which calls mailx in the following way: print_mail_text | sed -e s/[^[:print:]]//g | rootsign | mail -s $subject $recipients -- -F Bootmail -f $FROM_MAIL Here the options -F and -f are used to set the From: header in the resulting mail message. This is now broken and results in error messages like these in /var/log/mail.log (on systems that run Postfix): Jan 26 16:20:09 example01 postfix/error[31885]: 4351640CB7: to=-f...@web01.example.com, orig_to=-F, relay=none, delay=0.16, delays=0.12/0/0/0.05, dsn=5.1.3, status=bounced (bad address syntax) Is this change going to stay for good? In that case we need to report a bug against the Bootmail package (and probably quite a few others) to change the mail commandline to use the -a commandline switch for specifying additional mail headers. I find it disconcerting that a security update completely removes functionality that has been available and expected for many years without providing a proper compatibility layer. Is this really the way to do this? ** Affects: bsd-mailx (Ubuntu) Importance: Undecided Status: New ** Description changed: - The security update of bsd-mailx (8.1.2-0.2006cvs-1ubuntu0.1) - removes bsd-mailx's support for specifying sendmail options after -- - on the commandline. + The security update of bsd-mailx (8.1.2-0.2006cvs-1ubuntu0.1 on + Ubuntu 12.04) removes bsd-mailx's support for specifying sendmail + options after -- on the commandline. This breaks any script that supplies classic sendmail options like -F or -f on the mail commandline. A prominent example is Bootmail, which calls mailx in the following way: print_mail_text | sed -e s/[^[:print:]]//g | rootsign | mail -s $subject $recipients -- -F Bootmail -f $FROM_MAIL Here the options -F and -f are used to set the From: header in the resulting mail message. This is now broken and results in error messages like these in /var/log/mail.log (on systems that run Postfix): Jan 26 16:20:09 example01 postfix/error[31885]: 4351640CB7: to=-f...@web01.example.com, orig_to=-F, relay=none, delay=0.16, delays=0.12/0/0/0.05, dsn=5.1.3, status=bounced (bad address syntax) Is this change going to stay for good? In that case we need to report a bug against the Bootmail package (and probably quite a few others) to change the mail commandline to use the -a commandline switch for specifying additional mail headers. I find it disconcerting that a security update completely removes functionality that has been available and expected for many years without providing a proper compatibility layer. Is this really the way to do this? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bsd-mailx in Ubuntu. https://bugs.launchpad.net/bugs/1414684 Title: bsd-mailx no longer supports sendmail options, thus breaking existing scripts (like Bootmail) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bsd-mailx/+bug/1414684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1325560] Re: kvm virtio netdevs lose network connectivity under enough load
Installing 3.14.1 as per comment #17 fixed these connectivity issues for us as well, but it doesn't look like the 3.14.1 kernel made it anywhere near the 14.04.1 release. There is also no mention of this or any related bugs in https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummary/14.04.1. What else can we do except manually install 3.14.1, which is obviously not a proper solution? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1325560 Title: kvm virtio netdevs lose network connectivity under enough load To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/1325560/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 989452] Re: oneiric's virt-viewer can't connect to console of precise's virtual machines
Serge, at the moment it is a bit difficult but in a few weeks I could have some spare machines available on which I could install Quantal. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/989452 Title: oneiric's virt-viewer can't connect to console of precise's virtual machines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/989452/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 989452] Re: oneiric's virt-viewer can't connect to console of precise's virtual machines
There are currently multiple bugs that deal with virt-manager/virt- viewer not being able to connect to a VNC console of a Libvirt/KVM domain, such as #837275, #995320 and this one. The problem remains, however. On a Precise server (12.04.1) where /etc/libvirt/qemu.conf has set vnc_listen = 0.0.0.0 vnc_tls = 0 no VNC connection is possible with neither virt-manager, nor virt-viewer from a remote client. Virt-manager just displays the dreaded Error: viewer connection to hypervisor host got refused or disconnected! and virt-viewer says Unable to connect to the graphic server 0:5916 when called like this: virt-viewer -c qemu+tcp://kvmhost04/system domain01.example.com Libvirt is configured to allow unencrypted TCP connections (because of bug #1001798) so regular virt-manager interaction works, just not the VNC console. This must be a virt-manager, Libvirt or QEMU issue, because using a VNC viewer like xtightvncviewer to connect to the domain's VNC port works fine: xtightvncviewer kvmhost04:5916 So what can we do? I see no interesting log entries anywhere that would begin to explain what is going on here. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/989452 Title: oneiric's virt-viewer can't connect to console of precise's virtual machines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/989452/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 989452] Re: oneiric's virt-viewer can't connect to console of precise's virtual machines
Addendum: All this with Precise machines (client and server), no Oneiric or earlier involved. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/989452 Title: oneiric's virt-viewer can't connect to console of precise's virtual machines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/989452/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 423252] Re: NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd
Just to add something that has nothing to do directly with this bug, but is related: we have been using SSSD for quite a while now, using Timo Aaltonen's PPA https://launchpad.net/~sssd/+archive/updates and could not be happier. In my opinion SSSD is the superior solution for all things authn/authz, tying together LDAP, Kerberos and PAM. There are still some minor Ubuntu-related issues with the ordering of the involved PAM modules but everything works very well, apart from that. I think Ubuntu would do well to properly integrate and incorporate SSSD, especially in the Server edition. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libnss-ldap in Ubuntu. https://bugs.launchpad.net/bugs/423252 Title: NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/423252/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 350936] Re: Should shut down domains on system shutdown
So is there any way the proper fix will make it into Lucid? Or has that ship sailed? In the meantime I have applied Sebastian Marsching's method which works quite well. Thanks for that, Sebastian. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kvm in Ubuntu. https://bugs.launchpad.net/bugs/350936 Title: Should shut down domains on system shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/350936/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 350936] Re: Should shut down domains on system shutdown
Clint, great to hear, thanks. We have many Lucid servers in production, but no Maverick or Natty, so the fix getting into Lucid is most important for us. But if time and resources allow it, backporting the fix to Maverick and Natty would certainly be nice. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/350936 Title: Should shut down domains on system shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/350936/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 350936] Re: Should shut down domains on system shutdown
Orticio, this is an English-speaking forum. Please stop asking people to speak Spanish. Translated by Google: Este es un foro de habla Inglés. Por favor, deje de pedir a la gente a hablar español. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kvm in ubuntu. https://bugs.launchpad.net/bugs/350936 Title: Should shut down domains on system shutdown -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 81242] Re: postfix-ldap is linked against gnuTLS
For what it's worth this is still a problem in 10.04.1 and Postfix 2.7.0-1. Manually copying /dev/random and /dev/urandom to /var/spool/postfix/dev works around the problem. I also find it quite strange that this doesn't affect more people. In fact this bug seems to have been completely forgotten. Is nobody using Postfix, LDAP and SSL/TLS on Ubuntu? -- postfix-ldap is linked against gnuTLS https://bugs.launchpad.net/bugs/81242 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to postfix in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 495394] Re: autostart almost always fails on boot time host
Thanks for the new patch! I tested it just now and it seems to work, but it's always hard to tell when dealing with race conditions. I'll keep testing. Out of interest, the only change (apart from the more verbose way of testing the $interface variable) is the added break statement, right? I am not familiar enough with the Upstart boot process but why does this change make the job work correctly? I also have not found any info on what exactly ifquery does. Does it just read /etc/network/interfaces and extract the interface names? Anyway, thanks again! -- autostart almost always fails on boot time host https://bugs.launchpad.net/bugs/495394 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 495394] Re: autostart almost always fails on boot time host
Mika, thank you for the patch and new upstart job. We are trying it out here and find that the bridged-network job seems to be waiting forever for a net-device-up signal to be emitted, thus keeping libvirtd-bin from starting. I only now have begun reading up on upstart but so far I can't find any obvious flaws in your job definition. Waiting on the net-device-up signal which is emitted every time a network interface comes up (/etc/network/if-up.d/upstart) and then checking the status of the bridges seems the correct way but it doesn't work for us. Did you take any additional steps in order to get this upstart job to work correctly? -- autostart almost always fails on boot time host https://bugs.launchpad.net/bugs/495394 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 578332] [NEW] AppArmor blocks hot-attaching of USB devices
Public bug reported: On Ubuntu 10.04 server, after applying the fixes to Libvirt's AppArmor profiles as discussed in bug 545795 the hot-attachment of USB devices is blocked/denied by AppArmor. Hot-attachment means: a KVM-based VM is running and a USB devices connected to the underlying host is to be attached/passed-through to the VM while it is running. This can be accomplished by using virt-manager: 1. Open the Details window of the virtual machine in question 2. Klick Add Hardware 3. Select Physical Host Device, Next 4. Select USB device and choose the device to be attached (in our case a USB card reader), Next 5. Finish The logfile for the machine in question immediately shows: usb_create: no bus specified, using usb.0 for usb-host husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /var/log/kern.log accordingly shows kernel: [79029.932635] type=1503 audit(1272985279.341:1009): operation=open pid=23782 parent=1 profile=libvirt-959806d1-327a-cd14 -6b3f-ddeee8a19d0e requested_mask=rw:: denied_mask=rw:: fsuid=0 ouid=0 name=/dev/bus/usb/005/002 This happens because AppArmor doesn't allow Libvirt access to /dev/bus/usb/**. Note that this works fine when the machine in question is shut down prior to attaching the USB device but that is exactly not the desired behaviour of hot-attaching devices. This can be fixed quite simply by allowing read-write access to /dev/bus/usb/**. I don't know if that needs to be added to the profile abstractions/libvirt-qemu or usr.lib.libvirt.virt-aa-helper. I believe it is the latter, but I am not sure. apparmor: 2.5-0ubuntu3 libvirt-bin: 0.7.5-5ubuntu27 Description:Ubuntu 10.04 LTS Release:10.04 ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New -- AppArmor blocks hot-attaching of USB devices https://bugs.launchpad.net/bugs/578332 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 578332] Re: AppArmor blocks hotplugging of USB devices
** Summary changed: - AppArmor blocks hot-attaching of USB devices + AppArmor blocks hotplugging of USB devices ** Description changed: On Ubuntu 10.04 server, after applying the fixes to Libvirt's AppArmor - profiles as discussed in bug 545795 the hot-attachment of USB devices is - blocked/denied by AppArmor. Hot-attachment means: a KVM-based VM is - running and a USB devices connected to the underlying host is to be - attached/passed-through to the VM while it is running. This can be - accomplished by using virt-manager: + profiles as discussed in bug 545795 the hotplugging of USB devices is + blocked/denied by AppArmor. Hotplugging means: a KVM-based VM is running + and a USB devices connected to the underlying host is to be attached + /passed-through to the VM while it is running. This can be accomplished + by using virt-manager: 1. Open the Details window of the virtual machine in question 2. Klick Add Hardware 3. Select Physical Host Device, Next 4. Select USB device and choose the device to be attached (in our case a USB card reader), Next 5. Finish The logfile for the machine in question immediately shows: usb_create: no bus specified, using usb.0 for usb-host husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /var/log/kern.log accordingly shows kernel: [79029.932635] type=1503 audit(1272985279.341:1009): operation=open pid=23782 parent=1 profile=libvirt-959806d1-327a-cd14 -6b3f-ddeee8a19d0e requested_mask=rw:: denied_mask=rw:: fsuid=0 ouid=0 name=/dev/bus/usb/005/002 This happens because AppArmor doesn't allow Libvirt access to /dev/bus/usb/**. Note that this works fine when the machine in question is shut down prior to attaching the USB device but that is exactly not the desired behaviour of hot-attaching devices. This can be fixed quite simply by allowing read-write access to /dev/bus/usb/**. I don't know if that needs to be added to the profile abstractions/libvirt-qemu or usr.lib.libvirt.virt-aa-helper. I believe it is the latter, but I am not sure. apparmor: 2.5-0ubuntu3 libvirt-bin: 0.7.5-5ubuntu27 Description:Ubuntu 10.04 LTS Release:10.04 -- AppArmor blocks hotplugging of USB devices https://bugs.launchpad.net/bugs/578332 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 545795] Re: apparmor driver blocks access to hostdev and pcidev devices
Looks like I found it. The VM in my case is trying to access /sys/devices/pci:00/:00:1e.0/:01:04.4/usb6/devnum but the abstractions/libvirt-qemu profile only allows /sys/bus/usb/devices/ r, /sys/devices/*/*/usb[0-9]*/** r, when it should (also) allow /sys/devices/*/*/*/usb[0-9]*/** r, With this line added the guest boots fine and immediately gets access to the USB device. I have attached a patch for this one-line fix, hope it helps. ** Patch added: One-line fix for hostdev access to USB devices http://launchpadlibrarian.net/47796844/libvirt-qemu.patch -- apparmor driver blocks access to hostdev and pcidev devices https://bugs.launchpad.net/bugs/545795 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 545795] Re: apparmor driver blocks access to hostdev and pcidev devices
Jamie, yes this fixes it. thank you! I notice however some redundancies between abstractions/libvirt-qemu and usr.lib.libvirt.virt-aa-helper? At least the line /sys/bus/usb/devices/ r, appears in both, don't know if that matters any, though. So that's good :) But now I have discovered something else. When booting a VM that has a USB device included in its XML definition (like here: https://daff.pseudoterminal.org/files/vm-usb.txt) now thanks to this fix works fine. *However* trying to attach a USB device while the VM is running (using virt-manager in my case) results in these messages in /var/log/libvirt/qemu/vm.log: usb_create: no bus specified, using usb.0 for usb-host husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 /dev/bus/usb/005/002: Permission denied husb: open device 5.2 And in /var/log/kern.log: May 4 17:01:19 TESTHOST kernel: [79029.932635] type=1503 audit(1272985279.341:1009): operation=open pid=23782 parent=1 profile =libvirt-959806d1-327a-cd14-6b3f-ddeee8a19d0e requested_mask=rw:: denied_mask=rw:: fsuid=0 ouid=0 name=/dev/bus/usb/005/002 So it seems that access to /dev/bus/usb/** is needed as well? -- apparmor driver blocks access to hostdev and pcidev devices https://bugs.launchpad.net/bugs/545795 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 545795] Re: apparmor driver blocks access to hostdev and pcidev devices
Oh and it seems that disconnecting/detaching an USB device from the running VM doesn't work at all? virt-manager complains: Device could not be removed from the running machine. This change will take effect after the next VM reboot But this has probably nothing to do with AppArmor and may just be a shortcoming of Libvirt? Just pointing it out here since it seems to fit. -- apparmor driver blocks access to hostdev and pcidev devices https://bugs.launchpad.net/bugs/545795 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 545795] Re: apparmor driver blocks access to hostdev and pcidev devices
I'm sorry to post to this bug that has a status of Fix released but I am not sure it is really fixed. I have a situation similar too the original poster's concerning a USB card reader that won't make it past AppArmor it seems. Using libvirt-bin 0.7.5-5ubuntu27. Situation: one of our servers was upgraded from Ubuntu 9.10 to 10.04 today. The server runs a few Ubuntu 9.10 VMs, nothing fancy or out of the ordinary. These VMs were defined and installed a few weeks ago, prior to the release of and update to Ubuntu 10.04 (if that matters at all). We've had problems with AppArmor and Libvirt/KVM before so we disabled AppArmor and pass-through of the USB card readers worked fine this way. This situation was not ideal from a security point-of-view but since the host and guests are strictly for internal test and development purposes we went with it. Now I see that a lot has happened with regards to AppArmor, USB and PCI pass-through and Libvirt, so tried again enabling AppArmor. Alas, when starting a VM dmesg and /var/log/kern.log show these entries, repeating every second it seems: May 3 19:44:18 TESTHOST kernel: [ 2407.509182] type=1503 audit(1272908658.618:785): operation=open pid=1532 parent=1 profile =libvirt-959806d1-327a-cd14-6b3f-ddeee8a19d0e requested_mask=r:: denied_mask=r:: fsuid=0 ouid=0 name=/sys/devices/pci:00/:00:1e.0/:01:04.4/usb6/devnum The guest of course does not get to see anything of the USB device in question. Please find the XML definition of the guest in question here: https://daff.pseudoterminal.org/files/vm-usb.txt After disabling AppArmor (/etc/init.d/apparmor stop) the USB device is again visible in the guest. Why would this happen? The file /etc/apparmor.d/usr.lib.libvirt.virt-aa- helper explicitly states that access to /sys/devices/** should be allowed. Am I missing anything? I can experiment and run tests on this server for the next week or so, so please tell me if I can help debugging anything. -- apparmor driver blocks access to hostdev and pcidev devices https://bugs.launchpad.net/bugs/545795 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 303882] Re: python-vm-builder --raw doesn't set size correctly
Would also like to see this fixed for karmic. Using python-vmbuilder
0.11.3-0ubuntu1 and the same error occurs when trying to use a 10G LVM
volume as a --raw device. I assume this is the same bug.
sudo vmbuilder kvm ubuntu --debug --verbose -m 2048 --raw=/dev/mapper/vg
--storage-lv--chat_root --rootsize=8G --swapsize=2G --suite=karmic ...
Traceback (most recent call last):
File /usr/bin/vmbuilder, line 29, in module
VMBuilder.run()
File /usr/lib/python2.6/dist-packages/VMBuilder/__init__.py, line 65, in run
frontend.run()
File /usr/lib/python2.6/dist-packages/VMBuilder/plugins/cli/__init__.py,
line 66, in run
self.set_disk_layout(vm)
File /usr/lib/python2.6/dist-packages/VMBuilder/plugins/cli/__init__.py,
line 105, in set_disk_layout
disk.add_part(offset, vm.swapsize, 'swap', 'swap')
File /usr/lib/python2.6/dist-packages/VMBuilder/disk.py, line 189, in
add_part
raise Exception('Partition is out of bounds. start=%d, end=%d, disksize=%d'
% (begin,end,self.size))
Exception: Partition is out of bounds. start=8192, end=10239, disksize=5120
--
python-vm-builder --raw doesn't set size correctly
https://bugs.launchpad.net/bugs/303882
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 517067] Re: Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt)
You are right of course, /etc/fstab on the guest contains /dev/sdXY entries. These get generated by /usr/share/pyshared/VMBuilder/plugins/ubuntu/feisty.py as you mentioned. After changing all /dev/sdXY to /dev/vdXY I can indeed boot happily :) What threw me off was that QEMU did not (and does not) see these virtio- based drives when booting (see screenshots) and that changing the target device name in the domain definition (target dev='vda' bus='virtio'/ to target dev='sda' bus='virtio'/ and vice versa) does nothing. I suppose this has to do with the snippet of documentation I quoted previously and probably with the fact that the virtio driver is paravirtualized so QEMU doesn't do any of the emulation it would do with IDE- or SCSI-based buses. Should have thought of that earlier. So creating guests in the manner I described in my original post using vmbuilder works after applying your one-line fix to /usr/share/pyshared/VMBuilder/plugins/ubuntu/feisty.py. I am not sure where this bug lies since I am just getting to know the more advanced aspects of libvirt but I suppose vmbuider is to blame. That's understandable given that it is still somewhat young and cannot consider all possible combinations and varieties of libvirt options. Too bad virt-install is mostly useless for quickly creating and deploying guests for testing purposes. I like your solution b.) but doesn't that add yet another level of indirection and complicates guest setup even more? -- Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt) https://bugs.launchpad.net/bugs/517067 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to vm-builder in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 517067] Re: Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt)
Thanks for the comment, but how do you figure? I did not change anything after the fact, I modified the template used for installation and setup of the guest domain. First, it seems to depend on the bus type whether the virtual disks are at all visible to QEMU, as can be seen from the screenshots. At that point logical device names are of no consequence, yet, because the kernel isn't even booted. Second, it does not matter whether the disks are called vda or hda (the default) in the libvirt domain definition. From the documentation: The dev attribute indicates the logical device name. The actual device name specified is not guaranteed to map to the device name in the guest OS. Treat it as a device ordering hint. This is further supported by the fact that upon switching the bus type to ide the disks are visible both to QEMU and to the booted guest Linux kernel but the logical device name in the domain definition is still vda-based. Third, the logical device name is defined and set early during installation/setup of the guest since it looks at the modified template in /etc/vmbuilder/libvirt. So the installation procedure is aware that disks are named vda in the definition and takes that into account (or should take that into account). It does not matter whether it is hda oder vda there (I tried both, multiple times), /etc/fstab will always have /dev/sdX* set. So I don't think that is the problem here, but I will try again. Thanks for the comment, again! -- Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt) https://bugs.launchpad.net/bugs/517067 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 517067] [NEW] Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt)
Public bug reported: Binary package hint: libvirt-bin I can reproduce that trying to use bus='virtio' for virtual disks in the definition of a libvirt domain makes virtual disks thus defined disappear in the eyes of KVM/QEMU. This leads to error messages like the following when booting, as well as disappearance of all partitions on that virtual disk, except for the root partition (that means especially that no swap space will be enabled): One or more of the mounts listed in /etc/fstab cannot yet be mounted: (ESC for recovery shell) swap: waiting for /dev/sda2 /opt: waiting for /dev/sda3 A screenshot is available here: https://daff.pseudoterminal.org/misc/mountfailed.png It also appears, just after starting the guest, that QEMU doesn't even recognize that there are hard disk drives present, it only sees the DVD drive. See the following screenshots for comparison. bus='ide' in virtual disk domain definition: https://daff.pseudoterminal.org/misc/bus_ide.png bus='virtio' in virtual disk domain definition: https://daff.pseudoterminal.org/misc/bus_virtio.png The result is that only the root partition, probably because of initramfs/initrd and GRUB magic, will be available to the guest when using virtio, and only when no partitions other than a swap partition have been defined during setup or installation of the guest. When only a swap partition is present the boot process succeeds but still complains that it is waiting for the swap partition to become available. When there are any other partitions the boot process just hangs with the error message described above. Background: I like to take advantage of the paravirtualized IO drivers offered for KVM-based guests. Using virtio as bus for block devices or model type for network interfaces in the right places in a libvirt domain definition enables those drivers. To facilitate and automate this when creating guests I edited the libvirt template for vmbuilder to automatically use virtio. Notice the target line: #for $disk in $disks disk type='file' device='disk' source file='$disk.filename' / target dev='vd$disk.devletters()' bus='virtio' / /disk #end for Now for creating a guest using vmbuilder, as per the Ubuntu Server Guide: # vmbuilder kvm ubuntu --dest=/storage/vms/foo -m 2048 --rootsize=4000 --optsize=4000 --hostname=foo --suite=karmic --bridge=br0 --overwrite --libvirt=qemu:///system --flavour=virtual --arch=amd64 --mirror=http://host:/ubuntu Here a root and an /opt partition are defined, both 4GB in size. Swap is defined automatically and defaults to 1GB. This works fine and results in the attached foo.xml libvirt domain definition. In particular the disk definition looks like this (again, notice the target line): disk type='file' device='disk' source file='/storage/vms/foo/disk0.qcow2'/ target dev='vda' bus='virtio'/ /disk This is what the libvirt and KVM documentation pages suggest. After starting this domain the results are as described above, i.e. either a hanging boot process or a missing swap partition. When changing the target bus definition to bus='ide' everything works correctly. The domain boots as expected and contains all partitions defined during setup. This has been completely reproducible for me and I can switch between a working guest domain and a non-working by changing bus='virtio' to bus='ide' in the domain definition. This is on a Ubuntu Server Edition installation. I have no idea if this is a libvirt problem or a problem with KVM or QEMU or something else entirely. More information follows and please also see the attached files. If there is anything else I can provide please tell me. lsb_release -rd: Description:Ubuntu 9.10 Release:9.10 apt-cache policy libvirt-bin libvirt-bin: Installed: 0.7.0-1ubuntu13.1 Candidate: 0.7.0-1ubuntu13.1 Version table: *** 0.7.0-1ubuntu13.1 0 500 http://at.archive.ubuntu.com karmic-updates/main Packages 100 /var/lib/dpkg/status 0.7.0-1ubuntu13 0 500 http://at.archive.ubuntu.com karmic/main Packages uname -a: Linux dhcp155 2.6.31-17-server #54-Ubuntu SMP Thu Dec 10 18:06:56 UTC 2009 x86_64 GNU/Linux ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New -- Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt) https://bugs.launchpad.net/bugs/517067 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 517067] Re: Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt)
** Attachment added: Domain definition for guest foo, using virtio for block devices http://launchpadlibrarian.net/38748978/foo.xml -- Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt) https://bugs.launchpad.net/bugs/517067 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 368962] Re: [Jaunty] Can't reboot kvm virtual machines using virsh
This bug doesn't seem to have gotten much attention since July last year
but I can report that the issue still exists on Karmic using libvirt-bin
0.7.0-1ubuntu13.1:
$ virsh reboot foo1
Connecting to uri: qemu:///system
error: Failed to reboot domain foo1
error: this function is not supported by the hypervisor: virDomainReboot
The stack trace printed by virt-manager says the same:
Traceback (most recent call last):
File /usr/share/virt-manager/virtManager/engine.py, line 523, in
reboot_domain
vm.reboot()
File /usr/share/virt-manager/virtManager/domain.py, line 554, in reboot
self.vm.reboot(0)
File /usr/lib/python2.6/dist-packages/libvirt.py, line 398, in reboot
if ret == -1: raise libvirtError ('virDomainReboot() failed', dom=self)
libvirtError: this function is not supported by the hypervisor: virDomainReboot
Anything we users can or should do here?
--
[Jaunty] Can't reboot kvm virtual machines using virsh
https://bugs.launchpad.net/bugs/368962
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
