December 2011 - virt - Fedora mailing-lists

Log filling with bogus(?) VLAN-related error message
by Ian Pilcher 08 May '12

08 May '12

My syslog is getting flooded with messages like this: Nov 19 15:27:16 ian libvirtd: 15:27:16.949: 2725: error : virInterfaceDefParseXML:807 : XML description for vlan interface misses the vlan element is not well formed or invalid I do have tagged VLAN interfaces on the host (br0.1, br0.4, and br0.251), but none of my VMs are using them. I am not using any libvirt-managed networks at all: [pilcher@ian ~]$ sudo virsh net-list --all Name State Autostart ----------------------------------------- default inactive no I am running libvirt-0.8.8-7.fc15.x86_64. Any ideas? Thanks! -- ======================================================================== Ian Pilcher arequipeno(a)gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ========================================================================

2 3

Close a VM, virt-manager loses connection
by Jerry James 29 Jan '12

29 Jan '12

I'm having a problem with multiple VMs and virt-manager on a Fedora 16 x86_64 machine. When I have multiple VMs running and shut one down, frequently virt-manager loses its connection. All of my VM windows disappear, and I'm left looking at a dialog box that says (after expanding the "Details" tab): Error polling connection 'qemu:///system': Unable to read from monitor: Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 440, in _tick conn.tick() File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick vm.tick(now) File "/usr/share/virt-manager/virtManager/domain.py", line 1531, in tick info = self._backend.info() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1411, in info if ret is None: raise libvirtError ('virDomainGetInfo() failed', dom=self) libvirtError: Unable to read from monitor: Connection reset by peer Simply reconnecting in virt-manager usually works, and then I can reopen windows for the VMs that are still running. HOWEVER, yesterday I had this happen and one of my running VMs was NOT listed. I just about panicked, thinking it had been deleted somehow. However, restarting libvirtd made it show up again. Is this a known problem? If not, what component should I file a bug against? Thanks, -- Jerry James http://www.jamezone.org/

4 4

Re: [fedora-virt] Routing to guests
by Robert Thiem 15 Jan '12

15 Jan '12

> From: Philip Rhoades > I can ssh from/to the host/guest OK but how do I set up a route (or > whatever is necessary) so that another machine: > eth0: 192.168.0.12 > can ssh to the guest? - "ssh 192.168.122.68" gives "no route to host" - > http://docs.fedoraproject.org/virtualization-guide/f12/en-US/html/ but > the problem does not seem to be covered there. Alexander is correct in saying that bridging would allow you to do that. There are two networking discussed in the guide. The first is a NAT (network address translation), in which the guests are given "private" ip addresses and any outbound traffic appears to be coming from the host machine's IP address. This is the same as the setup on your ADSL router where the internal network machines get addresses of 192.168.x.x but the internet sees your requests as coming from the IP address of your router. There should be lots of documentation in linux firewalling guides under sections on NAT (or possibly called IP Masquerading in some). Have a look at these for information on port forwarding to reveal services inside the virtual (such as ssh). The other option is bridging. This shares the physical network interface of the host with the guest. In this case the VM acts as though it's a machine plugged into the same subnet as the host, its services are accessible like those of the host and it's as vulnerable to attack as the host. Robert

9 13

Virtual CD-ROM & floppy problems in F16
by Ian Pilcher 03 Jan '12

03 Jan '12

I am trying to set up a (32-bit) Windows 7 guest on Fedora 16, and I've run into a couple of irritating problems. 1. The guest does not seem to recognize the virtual floppy drive at all. I've used virt-manager to create a virtual floppy drive (and controller), confirmed that it appears in the XML, and attached the VirtIO driver VFD, but the guest is acting as if it doesn't have a floppy drive at all -- both during installation and after I install to an emulated IDE disk. 2. I am unable to attach an ISO file to the virtual CD-ROM. Clicking on the "Attach" button in virt-manager has no effect. The only way I've been able to achieve this is to shut down the guest and delete and recreate the CD-ROM. Is anyone seeing anything like this? Any ideas what could be going on? Thanks! -- ======================================================================== Ian Pilcher arequipeno(a)gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ========================================================================

3 4

Dissapearing Cursor F17 guests
by Frank Murphy 31 Dec '11

31 Dec '11

I have a dissapearing cursor in some F17\Rawhide guests. Happens with both spice\vnc. differents video qxl,cirrus etc. F15\16 guests are fine. Have removed tablet in case that was the problem, still there with ps\2 emu. I cannot remove ps2 to test the other way around. Any ideas. F16 host, with F17 libvirt + deps. (to fix the losing connectiion problem) -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org

1 0

EFI (UEFI)
by Frank Murphy 22 Dec '11

22 Dec '11

What is the best way to create a fake EFI\UEFI setup as a guest vm? (Current host F15+ virt-preview) -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org

2 1

[fedora-specific libvirt PATCH] qemu: replace deprecated fedora-13 machine type with pc-0.13
by Laine Stump 16 Dec '11

16 Dec '11

(I'm thinking of appying this patch to libvirt in the F15 and F16 branches, as well as Rawhide. The intent is to prepare everyone for qemu's removal of support for the "fedora-13" machine type, which will happen in F17 (already done in Rawhide)). This addresses https://bugzilla.redhat.com/show_bug.cgi?id=754772 . It should only be applied to Fedora builds of libvirt (it seems appropriate to apply it to all versions currently in support). Background: During the lifetime of Fedora 13, some features were backported into the F13 build of qemu-kvm from upstream. These features were part of the functionality of machine type "pc-0.13" in upstream qemu-kvm, so a special "fedora-13" machine type was created for the F13 qemu-kvm. Since this fedora-13 became the new "canonical machine type", all new domains created with F13 libvirt tools by default contained that machine type in their configuration file. With the release of Fedora 16, qemu-kvm initially removed support for this machine type, which caused failure of many guest configurations to start. qemu-kvm subsequently re-added the patch to support fedora-13, but with the promise that they could remove it with the release of Fedora 17. (see https://bugzilla.redhat.com/show_bug.cgi?id=748218 ). Solution: In order to create a repeat of the recent problems, prior to F17 existing guest configurations need to be updated to change fedora-13 to pc-0.13 (which has been determined to be equivalent for all practical purposes). That's what this patch does: Each time libvirtd is started, it calls virDomainLoadAllConfigs() which calls virDomainLoadConfig(); this function has been modified to check for os.machine == "fedora-13", and change it to "pc-0.13" then write the updated config back to disk. Also, any other time a domain definition is parsed, the parsed version in memory is changed to turn "fedora-13" into "pc-0.13". This handles domains that had been saved to disk prior to the upgrade, and are subsequently restarted. Finally, whenever a domain definition is formatted into a string, any occurence of fedora-13 is replaced with pc-0.13. This should deal with those cases where a domain was running at the time of upgrade, and is later saved/snapshotted. I had considered doing this with some sed commands in the specfile, but that wouldn't do anything to help the xml saved in image files. (Also, one of the xml tests was using the machine type "fedora-13", and since that machine type is treated specially by the rest of this patch, it was failing. It has been changed to use machine type pc-0.13 instead.) --- src/conf/domain_conf.c | 52 ++++++++++++++++++- .../qemuxml2argv-encrypted-disk.args | 2 +- .../qemuxml2argv-encrypted-disk.xml | 2 +- 3 files changed, 51 insertions(+), 5 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 75e51a0..bf3dd88 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -8061,7 +8061,25 @@ virDomainDefPtr virDomainDefParseString(virCapsPtr caps, unsigned int expectedVirtTypes, unsigned int flags) { - return virDomainDefParse(xmlStr, NULL, caps, expectedVirtTypes, flags); + virDomainDefPtr def + = virDomainDefParse(xmlStr, NULL, caps, expectedVirtTypes, flags); + + /* Fedora-specific HACK - treat fedora-13 and pc-0.13 as equivalent. + * This handles the case of domains that had been saved to an image file + * prior to upgrade (save or snapshot), then restarted/reverted. + */ + if (def && STREQ_NULLABLE(def->os.machine, "fedora-13")) { + VIR_FREE(def->os.machine); + if (!(def->os.machine = strdup("pc-0.13"))) { + virReportOOMError(); + virDomainDefFree(def); + def = NULL; + } else { + VIR_WARN("Replacing deprecated 'fedora-13' machine type " + "with equivalent 'pc-0.13' in domain %s xml", def->name); + } + } + return def; } virDomainDefPtr virDomainDefParseFile(virCapsPtr caps, @@ -11343,8 +11361,20 @@ virDomainDefFormatInternal(virDomainDefPtr def, virBufferAddLit(buf, " <type"); if (def->os.arch) virBufferAsprintf(buf, " arch='%s'", def->os.arch); - if (def->os.machine) - virBufferAsprintf(buf, " machine='%s'", def->os.machine); + if (def->os.machine) { + /* Fedora-specific HACK - replace "fedora-13" with "pc-0.13". + * This will catch XML being written to save/migration images + * of domains that were running when libvirtd was restarted at + * the time of upgrade. + */ + if (STREQ_NULLABLE(def->os.machine, "fedora-13")) { + virBufferAddLit(buf, " machine='pc-0.13'"); + VIR_WARN("substituting machine type 'fedora-13' with 'pc-0.13' " + "in domain %s", def->name); + } else { + virBufferAsprintf(buf, " machine='%s'", def->os.machine); + } + } /* * HACK: For xen driver we previously used bogus 'linux' as the * os type for paravirt, whereas capabilities declare it to @@ -11779,6 +11809,22 @@ static virDomainObjPtr virDomainLoadConfig(virCapsPtr caps, VIR_DOMAIN_XML_INACTIVE))) goto error; + /* Fedora-specific HACK - replace "fedora-13" with "pc-0.13". + * This updates all config files at the first restart of libvirt + * after upgrade. + */ + if (STREQ_NULLABLE(def->os.machine, "fedora-13")) { + VIR_FREE(def->os.machine); + if (!(def->os.machine = strdup("pc-0.13"))) { + virReportOOMError(); + goto error; + } + VIR_WARN("Replacing deprecated 'fedora-13' machine type " + "with equivalent 'pc-0.13' in domain %s configuration file", name); + if (virDomainSaveConfig(configDir, def) < 0) + goto error; + } + if ((autostartLink = virDomainConfigFile(autostartDir, name)) == NULL) goto error; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args index 1da0073..c6634fd 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args @@ -1,5 +1,5 @@ LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root \ -/usr/bin/qemu -S -M fedora-13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \ +/usr/bin/qemu -S -M pc-0.13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \ encryptdisk -uuid 496898a6-e6ff-f7c8-5dc2-3cf410945ee9 -nographic -nodefconfig \ -nodefaults -chardev socket,id=monitor,\ path=//var/lib/libvirt/qemu/encryptdisk.monitor,server,nowait -mon \ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml index f5e5d74..fdcf624 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml @@ -5,7 +5,7 @@ <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <os> - <type arch='i686' machine='fedora-13'>hvm</type> + <type arch='i686' machine='pc-0.13'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> -- 1.7.7.3

4 12

Suggestions for NFS mount options?
by Scott Baker 12 Dec '11

12 Dec '11

I have a virt frontend that runs the VMs, and another server that stores the VM images/configs and shares via NFS. On the frontend I mount /mnt/nfs/virt-stuff and then symlink /var/lib/libvirt/images and /etc/libvirt/ from the NFS mount point. Are there any "best practices" for NFS mount options? Do I need to worry about the filesystem on the VM store? Right now I'm just using EXT3 to store the images. Any advice on the best way to share/store the VM images would be appreciated. -- Scott Baker - Canby Telcom System Administrator - RHCE - 503.266.8253

2 3

Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud 08 Dec '11

08 Dec '11

> Date: Thu, 8 Dec 2011 12:33:38 -0500 > From: seth vidal <skvidal(a)fedoraproject.org> > > I answered Denis immediately at the first post and he concurred it was > a problem. I like to think the conversation evolved as we discussed. > Yes, the conversation has shifted... Indeed, I mixed two distinct ideas: 1. One corresponding to an actual use case: using a private/trusted cloud service to do scratch, chain or even massive builds. 2. Another one corresponding to a dream, really: a P2P cloud, just because it sounds exciting, and would certainly be a USP (unique selling point) for Fedora. >From the answers, it seems that both ideas ring a bell. And, of course, the dream does not seem doable, mainly for security reason. Or it could be implemented as a proof-of-concept of all the technologies and skills, which Fedora gathers under its umbrella? Nevertheless, for now, I am really interested by the item #1 above. For the #2, we never know. Maybe a GSoC, or something like that, could make it happen... Thanks for having shared your thoughts! Regards Denis

1 0

Re: [fedora-virt] kvm "tablet" device burning cpu cycles
by Eric Blake 08 Dec '11

08 Dec '11

[redirecting to the fedora virt list] On 12/06/2011 03:36 PM, Dennis Jacobfeuerborn wrote: > Hi, > I noticed that when you install a virtual system with virt-manager it > always installs a tablet device by default. > The problem is that this device consumes 10% of cpu resources of the host > according to "top" which should probably be considered a bug. The poor behavior of a tablet device should be raised against the qemu team, to see if it can be made more efficient. > What is worse is that removing the tablet also means no mouse pointer > showing up in a centos 6 guest which means you are pretty much forced to > use the tablet device. Meanwhile, sufficiently new qemu provides USB device emulation, which is more efficient than the PCI tablet emulation; although it is not as apparent whether typical guests support that device driver in their default install (one of the reasons we default to the older tablet emulation is that it is likely to have a driver pre-installed on most guest OSs). The idea of swapping the default to a USB pointer should be raised against virt-manager and/or python-virtinst, when installing a new-enough guest OS with new enough qemu support, while continuing to provide the compatible fallback of the tablet for older setups. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

4 3

Re: [fedora-virt] kvm "tablet" device burning cpu cycles
by Daniel P. Berrange 08 Dec '11

08 Dec '11

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 :|

1 0

Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud 07 Dec '11

07 Dec '11

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

1 0

Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud 07 Dec '11

07 Dec '11

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?

1 0

P2P Packaging/Koji Cloud
by Denis Arnaud 07 Dec '11

07 Dec '11

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

2 1

Re: [fedora-virt] [Fedora-xen] Installing Fedora 16 in Xen PV DomU under Debian Squeeze
by Virgil 05 Dec '11

05 Dec '11

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

1 0

hvm FC16 on FC14 host
by Virgil 04 Dec '11

04 Dec '11

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

1 0

libvirt 9.7 F15\F16 ?
by Frank Murphy 02 Dec '11

02 Dec '11

Is it possible to get the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=752718 Backported to F15\16. Is the 9.7 in rawhide taken from the F14.src? -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

virt December 2011