Re: [fedora-virt] kvm "tablet" device burning cpu cycles
by Daniel P. Berrange
On Thu, Dec 08, 2011 at 03:31:28PM +0000, Matthew Garrett wrote:
> On Wed, Dec 07, 2011 at 09:20:48AM +0000, Daniel P. Berrange wrote:
> > On Tue, Dec 06, 2011 at 04:33:43PM -0700, Eric Blake wrote:
> > > The poor behavior of a tablet device should be raised against the qemu
> > > team, to see if it can be made more efficient.
> >
> > This is a long standing problem, but it shouldn't be taking anywhree
> > near 10% of CPU.
>
> Is there any reason we're not enabling USB autosuspend on the virt
> devices?
I've no idea what that entails to be honest. It is probably a question
to raise on qemu-devel
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
12 years, 4 months
Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud
2011/12/7 Nicolas Mailhot <nicolas.mailhot(a)laposte.net>
> Concerning trust, the classic way it has been solved before (by seti…)
> is to farm the same build to several independant nodes, cheksum results
> and make sure they all agree
>
Again, we could use that P2P build system just to alleviate the centralised
Koji servers from the scratch builds, on one hand, and from the failing
builds on the other hand. That way, the centralised Koji servers would need
no alteration.
As a side note, rather than using Snap (and Augeas, and...), we (in my
department) tend to prefer Chef (http://www.opscode.com/chef/), which has
got a broader scope, and allows much more complex configurations and
automation tasks.
Denis
12 years, 4 months
Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud
2011/12/7 seth vidal <skvidal(a)fedoraproject.org>
> I've looked into spawning virt instances to do building and it is pretty
> doable. The problem with them being offered by volunteers is trust
> [...]
>
You are right. I had not thought at that... how naive of me :(
The volunteers/trustees would sign the builds with their own private keys,
for instance with their FAS keys. Then, we could have some
"trustworthiness" ratings for all the submitters, like we have today for
the packagers (new packager, proven-packager, sponsor). While the submitter
is still not trusted, the centralised Koji infrastructure can duplicate the
build, and check that it gives the same results. And even when the
submitter is trusted, some random duplicate builds can occur. If the
submitter taints the builds, it will be flagged as a potential "fraud". A
human being would have to have a look at it then.
Or, the VMs could do "scratch" builds (only). When those builds are
successful, the VMs then just act as a standard clients to the central Koji
servers, and the packages are re-built in that safe
infrastructure. Overall, the central Koji infrastructure would be
off-loaded from all the scratch builds, as well as from the failed builds.
Which is already not so bad, is it?
I've worked on some code to spawn off an instance, submit jobs + packages,
> build them (a chain-build so you don't have to keep respawning them) then
> collect all the results back to your local machine. It works - it requires
> setting up trusted images at those cloud providers but that's not very hard
> to do and keep current. Right now I'm porting the code to use a different
> cloud-communication API than I was using before.
>
That would be very cool. Do you intend to use DeltaCloud (
http://deltacloud.apache.org/), or something like that?
> I have a couple of systems inside the red hat colo that I had planned on
> reinstalling to f16 and setting up openstack on them to play with the same
> idea but on a local cloud instance.
>
For sure, I would like to set up something like that for my own usage.
Is all this inline with the problems you've thought about?
>
Yes, that is fully in-line, and very interesting!
Denis
PS: why isn't there a virtualisation SIG? As there is already a mailing
list, it may be just a question of adding the corresponding Wiki page?
12 years, 4 months
P2P Packaging/Koji Cloud
by Denis Arnaud
Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing all of
us, package maintainers, to build all of "our" Fedora packages. I guess
that that infrastructure is not cost-less for RedHat and and the quality of
service is great (for instance, the wait in the queues, before Koji
actually builds the packages submitted via the command-line client, is not
so long).
As Fedora is pretty advanced in the cloud/virtualisation arena, we could
imagine a "Koji Cloud", hosted on VMs offered by volunteers. For instance,
I could contribute a few VMs in Europe (hosted on http://www.ovh.co.uk/).
Our Cloud SIG (https://fedoraproject.org/wiki/Cloud_SIG) and/or Virt ML (
https://admin.fedoraproject.org/mailman/listinfo/virt and
https://fedoraproject.org/wiki/Getting_started_with_virtualization)/RedHat
ET (http://et.redhat.com/) colleagues could help designing and implementing
the following infrastructure:
* VM template/images, ready to be started on the volunteer's servers
everywhere in the world, 24x7.
- SSH public keys of Koji administrators would be part of the images,
so that they can have an easy access to them, just in case.
- Those VMs would update themselves automatically.
- The containers could be standardised as well. For instance,
ProxMox/OpenVZ or Fedora/CentOS with libvirt.
* A directory (LDAP, or something less centralised, like the address book
of Skype, for instance), keeping track of all those VMs:
- with the corresponding last known status;
- with the VM configurations (Fedora/CentOS release, CPU, memory, disk
usage, etc);
- with some rating corresponding to their quality of service (build
duration, reliability of the VM, MTBF, etc).
* A dispatcher system:
- which would route the Koji build requests to available VMs;
- collect the outcome of the builds (logs, RPM packages, statistics,
QoS, etc) and store them in the current ("centralised") Koji infrastructure.
As I am not a specialist of all those technologies, I may have forgotten a
lot of things, but you get the idea.
Doesn't it sound great? Does it sound realisable? Am I crazy to dream to
such an infrastructure?
Cheers
Denis
12 years, 4 months
Re: [fedora-virt] [Fedora-xen] Installing Fedora 16 in Xen PV DomU under Debian Squeeze
by Virgil
Just a quick FYI re: installing FC16 pv under xen-4.0.3-1.fc14.x86_64, which
probs applys to Debian.
I installed FC15 first. Then I installed FC16 over the top and told Anaconda
to use the existing parts.
Here's the script I used:
#!/bin/bash
virt-install \
--paravirt \
--name test \
--ram 1024 \
--os-type=linux --os-variant=fedora15 \
--file /dev/XenVG/test \
--graphics none \
--extra-args="console=hvc0 serial rd_NO_PLYMOUTH nogpt" \
--location http://bckup2007.wwe.com.au/iso/
I mounted the FC15 iso first. Then after the machine came up I killed it,
mounted the FC16 iso and installed again. Tell Anaconda to use the existing
partitions.
Finally have an FC16 pv machine that boots with the old pygrub and seems to
work. Obviously the GPT stuff isn't going, which is the root cause here.
The pv machine overcomes my hvm issue where yum update kills the host when it
goes to upgrade glibc in the domU.
Hope this helps someone, 'cause it took all day to figure it out :-)
V
On Tue, 6 Dec 2011 02:27:04 PM Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 02:36:46PM -0500, David Howland wrote:
> > Hi, I recently installed Fedora 16 in a Xen PV DomU and since I didn't
> > find a lot of information online, I wanted to share my procedure in case
> > it helps anyone else. My Dom0 is Debian Squeeze, which uses a kernel at
> > version 2.6.32.
>
> The pygrub issues you described were fixed and I believe are now in
> Xen 4.1.2. But that won't work for you since Debian is 4.0 I think.
> I think they can be back-ported. Would you be up for trying to back-port
> those patches and submit them to Debian Squeeze?
>
> (Just search for M A Young and pygrub on this mailing list - he posted
> the patches two months ago or so).
>
> > Because I deal with varying operating systems and because I prefer
> > fine-grained control over configuration, I don't use virt-* tools or GUI
> > front ends. I wanted to install the OS the regular way.
> >
> > The basic install path was to use the live DVD to install in an HVM,
> > then switch to a PV with pygrub. I want to use pygrub so that I don't
> > have to copy kernels and init images around everytime the OS updates
> > itself.
> >
> > pygrub caused me some trouble because the version in my system can't
> > handle GPT partitions, grub2, or ext4 - all of which are used by default
> > in Fedora 16.
> >
> > What follows isn't perfect, but should be useful for people who want to
> > install Fedora 16 in an environment similar to mine. Note that I'm
> > using x86_64 with VT-x, and that matters. Use your brain, and be
> > careful to recognize newlines that email may introduce.
> >
> >
> >
> >
> > *** Create hard drive image ***
> > dom0# mkdir -p /img/fedora
> >
> > - you can put it anywhere you want! This is just what I used.
> >
> > dom0# cd /img/fedora
> > dom0# dd if=/dev/zero of=xen-fedora-16.img bs=1M count=20000
> >
> > *** Download DVD image ***
> > dom0# cd /img/fedora
> > dom0# wget
> > http://download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/x86
> > _64/iso/Fedora-16-x86_64-DVD.iso
> >
> > *** Create HVM config file ***
> > dom0# cd /etc/xen
> > dom0# (edit fedora-16.hvm)
> > -----/etc/xen/fedora-16.hvm------------------------------
> > name = 'fedora-16'
> > vif = [ 'mac=aa:00:00:50:02:f0, bridge=xenbr0' ]
> > disk = [
> >
> > 'file:/img/fedora/xen-fedora-16.img,hda,w',
> > 'file:/img/fedora/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r',
> >
> > ]
> > boot = 'dca'
> >
> > kernel = '/usr/lib64/xen-4.0/boot/hvmloader'
> > device_model = '/usr/lib64/xen-4.0/bin/qemu-dm'
> > builder = 'hvm'
> >
> > memory = 2048
> > shadow_memory = 8
> > vcpus = 2
> > #pae = 1
> > acpi = 1
> > apic = 1
> > vnc = 1
> > vncconsole = 1
> > sdl = 0
> > stdvga = 0
> > usbdevice = 'tablet'
> > serial = 'pty'
> >
> > on_poweroff = 'destroy'
> > on_reboot = 'destroy'
> > on_crash = 'destroy'
> > ---------------------------------------------------------
> >
> > *** Install Fedora 16 ***
> > dom0# xm create fedora-16.hvm
> > domU# (connect to new VM with a VNC viewer - Quickly!)
> > domU# (press TAB at boot menu to edit the kernel command line)
> > domU# (add "nogpt" to command line, without quotes)
> > domU# (install fedora)
> >
> > - disable lvm
> > - in partition list, change /boot to ext2 instead of ext4
> > - after install finishes, let it shut down
> >
> > dom0# (edit fedora-16.hvm)
> >
> > - comment out
> >
> > "'file:/img/fedora/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r',"
> > dom0# xm create fedora-16.hvm
> > domU# (complete install)
> >
> > - should be at desktop now
> >
> > *** Enable SSH ***
> > domU# (open root shell)
> > domU# systemctl enable sshd.service
> > domU# systemctl start sshd.service
> >
> > *** Make a grub menu ***
> > domU# cd /boot/grub
> > domU# (edit menu.lst, using /boot/grub2/grub.cfg as a guide)
> >
> > - be sure to use your own kernal, init, and UUIDs from your own
> >
> > grub2 config
> > -----/boot/grub/menu.lst---------------------------------
> > -----/etc/xen/fedora-16.hvm------------------------------
> > timeout 3
> > default 0
> >
> > title Fedora Linux
> > root (hd0,0)
> > kernel /vmlinuz-3.1.2-1.fc16.x86_64
> > root=UUID=fc5702b1-65d9-426d-81d7-e52f31cb6a4a ro rd.md=0 rd.lvm=0
> > rd.dm=0 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0
> > LANG=en_US.UTF-8
> > initrd /initramfs-3.1.2-1.fc16.x86_64.img
> >
> > title Fedora Linux (recovery mode)
> > root (hd0,0)
> > kernel /vmlinuz-3.1.2-1.fc16.x86_64
> > root=UUID=fc5702b1-65d9-426d-81d7-e52f31cb6a4a ro single rd.md=0
> > rd.lvm=0 rd.dm=0 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb
> > rd.luks=0 LANG=en_US.UTF-8
> > initrd /initramfs-3.1.2-1.fc16.x86_64.img
> > ---------------------------------------------------------
> >
> > *** Make PV domU ***
> > domU# (shutdown VM)
> > dom0# cd /etc/xen
> > dom0# (edit fedora-16.pv)
> > -----/etc/xen/fedora-16.pv-------------------------------
> > name = 'fedora-16'
> > vif = [ 'mac=aa:00:00:50:02:f0, bridge=xenbr0' ]
> > disk = [
> >
> > 'file:/img/fedora/xen-fedora-16.img,xvda,w',
> >
> > ]
> >
> > bootloader = '/usr/lib/xen-4.0/bin/pygrub'
> >
> > memory = 2048
> > shadow_memory = 8
> > vcpus = 2
> > #pae = 1
> >
> > on_poweroff = 'destroy'
> > on_reboot = 'restart'
> > on_crash = 'restart'
> > ---------------------------------------------------------
> > dom0# xm create -c fedora-16.pv
> >
> > *** Enable VNC ***
> > domU# yum install vnc-server
> > domU# cp /lib/systemd/system/vncserver\@.service
> > /etc/systemd/system/vncserver\@\:0.service
> > domU# (edit /etc/systemd/system/vncserver\@\:0.service)
> > domU# (add user name instead of <USER>)
> > domU# (edit /etc/sysconfig/iptables)
> >
> > - insert new line: "-A INPUT -m state --state NEW -m tcp -p tcp
> >
> > --dport 5900 -j ACCEPT"
> > domU# service iptables restart
> > domU# systemctl enable vncserver@:0.service
> > domU# systemctl start vncserver@:0.service
> >
> >
> > thanks,
> > -d
> > --
> > xen mailing list
> > xen(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/xen
>
> --
> xen mailing list
> xen(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/xen
12 years, 4 months
hvm FC16 on FC14 host
by Virgil
Hi List,
I have a curious issue with a hvm fc16-i386 domU on fc14-x86-64 dom0.
Everything works, except... everytime yum (or anything really) update glibc
the entire machine reboots (that is the host reboots taking everything with
it).
It's possible to do the update by running the glibc update and crashing the
host, then recovering and continueing on after a cleanup in the domU. However,
building LiveCDs where the glibc must be installed into the image also kills
everything which is either unrecoverable or a reeeeel lot of work (i.e.
unrecoverable).
I'm at a roadblock now.
Any thoughts?
might try paravirt to see if that works.
Thanks in advance
V
12 years, 4 months
