[01:22] <hallyn> If that really has the same effect I'd be all for changing it.
[05:33] <koolhead17> hi all
[10:38] <TeTeT> Daviey: if you've got some time, do you have an idea how to triage https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/728018 further?
[10:38] <uvirtbot`> Launchpad bug 728018 in eucalyptus "10.04 LTS: Failure to start instance due to network address failure" [Undecided,New]
[10:40] <Daviey> TeTeT, looking
[10:41] <Daviey> TeTeT, remember when Lucid was released there was something like a 90% success rate?
[10:42] <TeTeT> Daviey: nope, don't remember that. So it this behaviour to be expected? What makes me ponder is, that I cannot start any new instances without tearing down the other ones first
[10:43] <Daviey> TeTeT, I suspect you have found a valid bug with 1.6.2...
[10:43] <Daviey> TeTeT, TBH, we really want to ditch 1.6.2...  and backport 2.0.X
[10:44] <Daviey> TeTeT, There were some SRU'd to address the failure to start and i /thought/ they were successful
[10:44] <TeTeT> Daviey: fine with me, I would test on 10.10, but the training cloud can only be setup with 10.04
[10:44] <Daviey> Upstream did a bunch of refactoring in 2.0 to address this properly.
[10:44] <Daviey> TeTeT, Yeah, i understand - it's a difficult situation
[10:45] <Daviey> TeTeT, The best i can suggest is raising it with upstream..
[10:45] <TeTeT> Daviey: who's raising it? Can I do that?
[10:46] <Daviey> TeTeT, I can see if i can get it escalated.
[10:46] <Daviey> TeTeT, Is this *urgent* or a pain?
[10:47] <TeTeT> Daviey: nothing urgent, just a finding of the uec scheduler script, I think I told you about. It does http and hadoop workloads on UEC right now
[10:48] <Daviey> TeTeT, Looking forward to seeing that in a demo :)
[10:48] <Daviey> TeTeT, Infact, i should just sign up to one of your courses. :)
[10:48] <TeTeT> Daviey: next one is start of April, you're welcome to join :)
[10:55] <Daviey> TeTeT, Fancy having one in the UK? :)
[10:56] <TeTeT> Daviey: it's all virtual, via spreed ;) so you can participate from around the world, though it starts 9am EST US
[10:59] <Daviey> Hmm.. filing with UTC conversion :)
[10:59] <Daviey> failing*
[10:59] <Daviey> UTC-8?
[11:02] <kim0> hallyn: ping
[11:02] <kim0> hallyn: I'm filing that MIR for spice and spice-protocol source packages, however the 1st requirement is that the pkgs are in Universe
[11:03] <kim0> afaict, they don't seem to be ?!
[11:19] <TeTeT> Daviey: 2pm your time I think, unless day time shifts are not the same
[11:22] <Daviey> TeTeT, oh great
[11:23] <Daviey> kim0, ah, looks like it might need a FFe then a MIR :)
[11:24]  * kim0 needs to learn about all the 3 letter acros :)
[11:24] <Daviey> kim0, sorry
[11:24] <kim0> Daviey: thanks for checking it out though
[11:24] <Daviey> Feature Freeze Exception
[11:24] <Daviey> BUT
[11:24] <Daviey> FFe can also mean Final Freeze Exception
[11:24] <Daviey> So, all good :)
[11:24] <kim0> hehe :)
[11:25] <kim0> hallyn: well, once you're up, let me know how to push this
[13:24] <hallyn> kim0: yeah soren mentioned this yesterday on #ubuntu-server.  So we need to get someone to sponsor getting it into universe.
[13:24] <hallyn> Someone like Daviey :)
[13:24] <hallyn> kim0: but have you tested it more?
[13:47] <Daviey> hallyn, I'm happy to review, and sponsor it to the NEW queue... but it will still need a FFe to get accepted into Universe
[13:49] <hallyn> Daviey: cool, thanks.
[13:49] <hallyn> Daviey: the question then is,
[13:49] <hallyn> with kvm being in main, what's the best way to handle dependency?
[13:50] <hallyn> Make it a 'Suggests', and let it just fail if user tries to use spice without the pkg from universe installed?
[13:57] <Daviey> hallyn, Do i understand correctly that this is built from the packages already in main?
[13:57] <Daviey> It's just a new binary package?
[14:00] <Daviey> Or is spice a separate source package?
[14:04] <Daviey> hallyn, ?
[14:05] <SpamapS> IIRC its its own source package
[14:05] <kim0> hallyn: hmm, no I haven't tested it yet .. I wanna do it now though
[14:07]  * kim0 installing
[14:08] <hallyn> Daviey: there are two new packages.  THey provide a library which qemu needs to be built against, plus a binary which is used as the client (in place of the vnc client)
[14:08] <hallyn> uh, well two new source packages.  More actual packages.
[14:10] <Daviey> hallyn, Then don't make any changes to qemu-kvm yet....
[14:10] <Daviey> hallyn, Show me the mone^D source.
[14:10] <Daviey> I'll upload it
[14:11] <Daviey> You deal with FFe of getting it in universe
[14:11] <Daviey> Erm, or kim0
[14:11] <Daviey> Get it ack'd for main
[14:11] <Daviey> Then make your changes to qemu-kvm
[14:12] <Daviey> then an archive admin will see it in component-mismatches, see the error - match it to the FFe, and promote it.
[14:16] <kim0> hallyn: In order to test I "apt-get install libspice-server1 spice-client" .. then launched qemu-kvm removing the -vnc option, and adding "-vga qxl -spice port=5930,disable-ticketing"
[14:16] <hallyn> Daviey: (I don't get the last sentence)  what kind of time frame is that?  How long usually in universe before MIR?
[14:16] <kim0> getting kvm: -spice port=5930,disable-ticketing: there is no option group "spice"
[14:16] <kim0> spice is not supported by this qemu build.
[14:16] <kim0> should I get a new kvm somehow?
[14:16] <hallyn> kim0: dpkg -l | grep qemu-kvm?
[14:16] <Daviey> hallyn, sorry, match it to the FFe|MIR reports.
[14:16] <kim0> ii  qemu-kvm                                 0.14.0~rc1+noroms-0ubuntu4                 Full virtualization on i386 and amd64 hardware
[14:17] <Daviey> hallyn, I think at this point in the cycle, potentially quite quickly.
[14:17] <hallyn> kim0: drat, there's been an update in main
[14:17] <kim0> hallyn: anyway I can force that version
[14:17] <hallyn> kim0: ok, cool
[14:17] <kim0> hallyn: I'm asking :)
[14:17] <hallyn> oh.  yes.
[14:18] <kim0> any way*
[14:18]  * kim0 slaps himself
[14:18] <hallyn> just go to https://launchpad.net/~serge-hallyn/+archive/spice/+packages  and d/l the qemu-kvm .debs, and dpkg -i them
[14:18] <kim0> ah sweet
[14:18] <kim0> hallyn: btw libspice 0.8 is out
[14:18] <hallyn> bleh
[14:20] <hallyn> kim0: let me try and package the final 0.14.0 today.  I'll try spice 0.8 after that.  It took enough finagling to get versions matching that I"m weary of changing again :)
[14:20] <kim0> hehe
[14:21] <hallyn> biab
[14:26] <SpamapS> So this spice thing has just dropped in universe, not even in debian, and we're MIR'ing it now to link qemu-kvm against it?
[14:26] <SpamapS> doesn't that sound a little... aggressive ?
[14:28] <Daviey> Hang on....
[14:28] <Daviey> qemu-kvm links against spice, or the other way around?
[14:28] <RoAkSoAx> -_-
[14:31] <kim0> trying to run kvm, it's stopping with "kvm: pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin"" .. any idea what's up
[14:31] <hallyn> kim0: it actually stops there?  That msg is usually spurious
[14:31] <kim0> hallyn: well I don't see any cpu usage
[14:31] <hallyn> kim0: you can install kvm-pxe which should provide that romfile if you need it
[14:31] <kim0> and spicec can't connect still
[14:32] <hallyn> kim0: what's your spicec cmdline?
[14:32] <kim0> spicec -h localhost -p 5930
[14:32] <kim0> that's kvm cmd line
[14:32] <kim0> /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name win7 -rtc base=localtime -boot c -drive file=/dev/vgkimo/win7,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=writeback -vga qxl -spice port=5930,disable-ticketing -device AC97,id=sound0,bus=pci.0,addr=0x6
[14:32] <hallyn> SpamapS: we want qemu-kvm with spice support.  if we can do that with spice in universe I'm fine with it.  But I'm not sure the best way to do that
[14:33] <hallyn> kim0: hm. that's all I did...
[14:34] <kim0> mm
[14:34] <hallyn> kim0: what iso are you using?
[14:34] <hallyn> kim0: I used redhat
[14:34] <kim0> hallyn: it's an already installed win7 VM
[14:34] <hallyn> kim0: ubuntu guests may not work.  our grub is unfriendly
[14:34] <hallyn> oh.  i don't know if you can do that.  Does win7 have the qxl drivers?
[14:34] <kim0> yeah
[14:35] <kim0> it's not even booting
[14:35] <kim0> hallyn: is there some way to get both vnc and spice .. so I can take a look
[14:35] <hallyn> kim0: get rid of the -boot c
[14:36] <hallyn> i don't think you can do both at once
[14:36] <kim0> hallyn: still not crunching
[14:36] <Daviey> hallyn, I'm not following.... Does kvm need to link against spice?
[14:36] <hallyn> however if you do -monitor stdio, you can do 'info qxl or 'invo spice'
[14:36] <hallyn> Daviey: yes
[14:36]  * Daviey didn't realise that.
[14:37] <Daviey> i just assumed it was some socket..
[14:37] <hallyn> no, it does it's own wholly different way of encoding the video channel
[14:38] <hallyn> kim0: all right i'm walking to the other room where I can test.  not sure i have a windows vm handy, i'll see
[14:39] <Daviey> hallyn / kim0: Would it be better to PPA this?
[14:41] <kim0> hallyn: changed it back to vnc .. still not booting
[14:41] <SpamapS> hallyn: if qemu-kvm ends up depending on libspice ... that won't work. :-/
[14:41] <kim0> I think something is wrong with me just launching direct command line ( I always used virsh before)
[14:41] <SpamapS> hallyn: however, if it can use spice plugin-style, where its not linked.. that could work.
[14:42] <kim0> hallyn: any way to force libvirt to pass the "-spice port=5930,disable-ticketing" part ?
[14:43] <hallyn> kim0: good :)  then it's not my fault :)
[14:43] <hallyn> SpamapS: you can't
[14:44] <hallyn> kim0: I think libvirt is supposed to support spice...  i'm not sure if there was a configure flag needed for that
[14:44] <hallyn> smoser: who exactly is the local xen expert?
[14:44] <Daviey> hallyn, traditionally it's been zul
[14:44] <hallyn> I could use some help in nailing down bug 728519
[14:44] <Daviey> hallyn, fwiw, upstream expressed interest in getting xen rocking on ubuntu
[14:44] <kim0> trying to start it from virsh now results in  "error: operation failed: failed to retrieve chardev info in qemu with 'info chardev'"
[14:45] <hallyn> when a guest is upgraded, one of its network links goes down;  but when reinstalled it never does
[14:45] <hallyn> zul: ^
[14:46] <Daviey> hallyn, zul is away
[14:46] <hallyn> oh, right.  i half remember that
[14:46] <hallyn> thanks
[14:47] <SpamapS> hallyn: yeah.. if its linked.. then a MIR is going to be required.
[14:48] <SpamapS> and, IMO, should not land post FF
[14:49] <hallyn> rephrase
[14:49] <hallyn> oh, meaning you'd object to an FFE
[14:50] <hallyn> SpamapS: I'll remember that next time you need a favor :)
[14:50] <hallyn> j/k.  i don't think i want to push it for natty
[14:50] <Daviey> hallyn, You don't lose anything by trying the process :)
[14:50] <Daviey> The worst that can happen is you'll get a nack
[14:50] <Daviey> and perhaps sacked. :)
[14:51] <hallyn> It has to be in by 12.04.  I feel better about ppa in 11.04.  Except that there are so many *&(*$% updates to qemu-kvm lately that keeping ppa uptodate will be painful
[14:53] <kim0> kvm launched now .. starring at a blank screen
[14:53] <kim0> trying to figure out hwo to debug it
[14:54] <SpamapS> hallyn: :)
[14:54] <hallyn> still windows?
[14:54] <kim0> yeah
[14:54] <hallyn> all right let me get settled into my call and then go to my test laptop.  biab
[14:54] <SpamapS> hallyn: isn't that what build recipes are for?
[14:54] <kim0> btw .. fedora had shipped a separate binary "qemu-spice" that seems to have spice enabled .. would that be helpful in our case
[14:55] <hallyn> SpamapS: maybe
[14:55] <SpamapS> we could actually do that
[14:55] <hallyn> SpamapS: but that still requires several steps (and lots of bandwidth) for each update
[14:55] <SpamapS> like we do for the unsavory bits of php
[14:55] <hallyn> uh,
[14:55] <hallyn> there are savory bits?
[14:56] <hallyn> kim0: sigh.  yes, I was hoping to avoid that, but that may be the thing to do
[14:56] <SpamapS> my favorite twit of last week... DEVOPS_BORAT -- "Openstack is PHP of cloud"
[14:56] <kim0> hehe :)
[14:57] <kim0> I removed the spice cli options, and kvm is still not starting for me
[14:57] <kim0> the sdl window mentioned "stopped"
[15:12] <ranger03> I am using UEC 64-bit Ubuntu 10.10 server. I dont have the ami at this moment.  I am using the default kernel 2.6.22-virtual..I would like to upgrade my kernel to the latest version. How can I do that? apt-get update;apt-get upgrade OR apt-get dist-upgrade?
[15:21] <kim0> ranger03: sudo apt-get update && sudo apt-get upgrade
[15:25] <ranger03> and that updates my UEC Ubuntu EC2 to the latest kernel available? Will I get to see the kernel version before the new kernel gets installed ?
[15:27] <kim0> ranger03: r u running on UEC or EC2
[15:29] <ranger03> EC2..
[15:29] <kim0> ranger03: ok, then it depends on whether the image you started is recent enough to be using pv-grub
[15:30] <kim0> in either cases, what I mentioned will show you the kernel version
[15:30] <kim0> and nothing bad will happen, either it will boot the new kernel, or the older one
[15:30] <kim0> after reboot verify kernel by "uname -r"
[15:30] <kim0> and see if it matches the new version that was just installed
[15:31] <ranger03> http://uec-images.ubuntu.com/maverick/current/
[15:32] <kim0> ranger03: when did you start your AMI
[15:32] <ranger03> trying to find my AMI on the web..I can find the AMI on AWS..but I want to find out where I got my first AMI
[15:33] <ranger03> http://aws.amazon.com/amis/4350?_encoding=UTF8&jiveRedirect=1
[15:33] <ranger03> us-east-1: ami-548c783d     <--64-bit EBS Ubuntu 10.10 US-EAST-1A
[15:36] <ranger03> logged into launchpad...some good info there as well
[15:38] <kim0> ranger03: you got nothing to worry about IMO
[15:38] <kim0> ranger03: just upgrade and see if it boots the new or old version
[15:39] <ranger03> Some weird kernel issues in Ubuntu 10.10 EC2...the default is pretty stable...but also has issues of kernel crashing under 'moderate to high io' load
[16:40] <koolhead17> hi all
[16:43] <RoAkSoAx> sadwin 28
[16:43] <RoAkSoAx> arrrrrrrrrrgh
[16:46] <kim0> koolhead17|afk: hey
[17:15] <hallyn> kim0: uh, well shoot.  it appears there is a bug in qemu-kvm debian/rules (which has been there for some time, and I refuse responsibility :).  So you probably don't have kvm support right now!
[17:15] <hallyn> fixing right now
[17:34] <hallyn> kim0: interesting.  I guess the build farms set up the environment 'just so' so that it worked anyway
[20:16] <gtaylor> Anyone else notice that Ubuntu EC2 instances take forever to come back up after a reboot?
[20:16] <gtaylor> Assuming it has something to do with an EBS or Ephemeral drive taking a while to mount
[20:16] <gtaylor> (I've got nobootwait for all secondary mounts, but the root EBS must be slow mounting sometimes)
[21:02] <kim0> hallyn: so I should wait for a kvm rebuild right .. that's fine
[21:07] <hallyn> kim0: no i don't think that was the problem
[21:12] <kim0> hallyn: My win7 VM is now blue screening .. I'll probably be reinstalling soonish
[21:29] <hallyn> kim0: but what does it do with -vga cirrus?
[21:29] <kim0> hallyn: is that different from -vga std ?
[21:29] <kim0> with std it bluescreens
[21:29] <hallyn> yup
[21:29] <kim0> now I'm reinstallation already .. so sorry :)
[21:30] <hallyn> heh, np
[21:30] <hallyn> debugging win7 != my cup of tea
[21:30] <kim0> wonder if I'll actually use lvm snapshots for testing
[21:30] <kim0> always diliked em
[21:30] <hallyn> sure!
[21:30] <kim0> disliked*
[21:31] <kim0> might try it though
[21:31] <kim0> can't btrfs grow up faster
[21:31] <kim0> :)
[21:32] <hallyn> seconded!
[21:33] <hallyn> but lvm snapshots shouls be perfect for potentially destructive testing
[21:33] <kim0> and while we're at it, release samba4 .. been waiting for that two employers back :)
[21:33]  * kim0 nods
[21:33] <kim0> will use it
[21:34] <kim0> hallyn: you're testing was launching a rhel installation with qxl ?
[21:34] <kim0> your*
[21:36] <hallyn> yeah, rhel6
[21:37] <hallyn> i will see if my technet subs is still good and try win7 in the morning though
[21:37] <kim0> I wonder if anaconda actually started X with qxl device backend
[21:37] <kim0> I remember reading spice has a "base" unaccelerated mode, something like vesa
[21:38]  * kim0 looks at Windows installation → 60% done
[21:38] <kim0> wonder if an SSD would make a huge difference
[22:10] <kim0> installation errored in a very sweet spot, allowing me to snapshot the disk at a "very first boot" state .. nice :)
[22:33] <kim0> hallyn: getting "
[22:33] <kim0> shm open failed .. permission denied
[22:34] <hallyn> where?
[22:35] <hallyn> are you still using virt-manager?
[22:35] <kim0> well yes
[22:35] <kim0> or virsh
[22:35] <kim0> This error is too common as well
[22:35] <kim0> error: operation failed: failed to retrieve chardev info in qemu with 'info chardev'
[22:35] <kim0> any idea what that means
[22:35] <hallyn> is there anything more in /var/log/libvirt/?
[22:36] <hallyn> libvirt is not very useful when testing basic qemu functionality :)
[22:36] <kim0> do_spice_init: statistics shm_open failed, Permission denied
[22:36] <kim0> 2011-03-09 00:36:32.947: shutting down
[22:37] <kim0> I'm not using "sudo virsh" if I should be
[22:37] <kim0> also a bit scared it might change ownership to root
[22:37] <kim0> hallyn: I guess the question is, how to allow my user shm_open permission
[22:39] <hallyn> ls -l /dev/shm
[22:40] <kim0> hallyn: many files owner by me there (pulse and mono)
[22:40] <kim0> owned*
[22:40] <hallyn> there should be a 'spice.%d' (%d being a pid)
[22:40] <kim0> it dies immediately
[22:40] <hallyn> I really think this is an issue with libvirt though
[22:41] <kim0> should I need a sudo somewhere ? :)
[22:41] <hallyn> For today I'd recommend doing an install with kvm on cmdline
[22:41] <hallyn> checking libvirt git log
[22:41] <kim0> I guess I can just launch the same installation with a direct kvm launch
[22:42] <kim0> I'm just never sure which of the 100 different options libvirt passes is needed :)
[22:42] <kim0> trying direct launch
[22:47] <kim0> hallyn: profit!!
[22:47] <kim0> works
[22:47] <hallyn> If you just do 'kvm -drive file=PATH,if=virtio,index=0 -cdrom win7.iso -m 1024M -smp 2 -vga qxl -spice port=9999,
[22:47] <hallyn> oh cool
[22:47] <hallyn> heh then I won't finish my cmdline :)
[22:47] <kim0> without installing the acceleration driver
[22:48] <hallyn> hm
[22:48] <kim0> probably in that "vesa" mode thing
[22:48] <kim0> now .. installing qxl drivers
[22:48] <hallyn> in any case i good luck :)
[22:48] <hallyn> i need to go bribe open-vm-tools to stop beating me up
[22:48] <kim0> hehe :)
[22:48] <kim0> cool
[22:51] <kim0> grr, qxl driver is not on the virtio-win iso
[22:57] <kim0> located qxl driver .. installing
[23:00] <kim0> woohoo more profit
[23:00] <kim0> testing video playback .. torture time
[23:06] <kim0> ok this definitely looks accelerated
[23:08] <hallyn> kim0: cool!
[23:08] <kim0> hallyn: yeah indeed ;)
[23:09] <kim0> if only we can fix get this working with virsh, so I can get audio too :D
[23:09] <kim0> s/fix//
[23:10] <kim0> My wild guess is, libvirt runs under a different user that can't access shm or something
[23:19] <hallyn> kim0: is there anything in /var/log/syslog, perhaps from apparmor, preventing the access?
[23:20] <kim0> hallyn: spot on
[23:20] <kim0> it is
[23:20] <kim0> how do I cure that :)
[23:21] <kim0> I wouldn't mind turning off apparmor for now
[23:21] <hallyn> kim0: what precisely is the error?
[23:21] <kim0> type=1400 audit(1299626386.897:119): apparmor="DENIED" operation="mknod" parent=1 profile="libvirt-d0aef59c-912b-0e75-9b34-d48807a5824d" name="/dev/shm/spice.6219" pid=6219 comm="kvm" requested_mask="c" denied_mask="c" fsuid=119 ouid=119
[23:21] <hallyn> kim0: we should be able to add a simple rule to /etc/apparmor.d/abstractions/libvirt-qemu I think
[23:22] <kim0> that would be lovely
[23:22] <kim0> hallyn: the strange part .. there's some other DENIED error as well
[23:22] <kim0> type=1400 audit(1299626386.527:117): apparmor="DENIED" operation="open" parent=23613 profile="/usr/lib/libvirt/virt-aa-helper" name="/tmp/virtio-win-1.1.16.vfd" pid=6207 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=119
[23:23] <kim0> but I'm pretty sure that vfd file was accessible
[23:23] <hallyn> Can you try adding '/dev/shm/spice.[0-9]* rw,' to that file?
[23:23]  * kim0 goes to add
[23:23] <hallyn> one sec
[23:24] <kim0> do I need to "reload" the rules somehow
[23:24] <hallyn> /etc/init.d/apparmor restart *might* work
[23:25] <hallyn> I'm still trying to verify whether 'w' will allow mknod
[23:25] <kim0> hallyn: it does :)
[23:26] <hallyn> excellent
[23:27] <hallyn> yay, open-vm-tools build success.  now to try the dkms part
[23:27] <hallyn> kim0: heading out for some dinner soon, ttyl
[23:27] <kim0> c ya
[23:32] <kim0> hallyn: if you care about it, virt-manager cannot display the graphics with the embedded viewer
[23:32] <kim0> it says "Cannot display graphical console type spice, no module named SpiceClientGtk"