Re: [Qemu-discuss] Help needed - LGPL Violation and Legal Threats
[chloridecull@Thunderlane ~/Downloads]$ strings nucore | grep qemu /usr/local/share/qemu /tmp/qemu-smb.%d /etc/qemu-ifup [qemu] show the version of qemu show kqemu information kqemu support: (qemu) activate logging of the specified items to '/tmp/qemu.log' qemu: Unsupported NIC: %s qemu: unsupported keyboard cmd=0x%02x qemu ... qemu.wav /tmp/qemu.log qemu: fatal: /dev/kqemu kqemu_flush_page: addr=%08x kqemu_flush: kqemu: cpu_exec: enter kqemu: interrupt v=%02x: Version mismatch between kqemu module and qemu (%08x %08x) - disabling kqemu use kqemu_set_notdirty: addr=%08lx kqemu: exception v=%02x e=%04x: kqemu: kqemu_cpu_exec: ret=0x%x It most certainly looks like qemu from running strings on it. AFAIK it should be enough evidence, but IANAL. Can't really prove it is a derivative that easily without access to both sources ;) On 11/02/2014 03:26 AM, Tom Cain wrote: > G'day QEMU wizards, > I've recently been made aware of an organization that seems to be pretty > actively sending out nastygrams to people who redistribute their software > which is a QEMU derivative. > It was my understanding that current versions of QEMU full system emulation > are GPL, and older versions (0.8.1) were LGPL. > The executables that this company distributes are not distributed with the > source, and the company has refused to release the source code upon request, > and has threatened legal action to all of those who host these files on their > websites. > My binary analysis shows that this is QEMU-0.8.1, can anyone confirm? > http://bigguyspinball.com/nucoresupport.shtml > > If so, it appears that this website is committing copyright infringement by > violating the terms of the LGPL. > > Any insight would be appreciated! I've communicated with the FSF and the > Software Freedom Conservancy, and they agree that hypothetically it is a > violation. I just need someone to confirm that the contents of that linux > binary are QEMU. From the looks of it, if this company is filing lawsuits, it > puts a MAJOR damper on the open source community, so any help is appreciated. > Thank you all! > Tom >
Re: [Qemu-discuss] Help needed - LGPL Violation and Legal Threats
> > I've recently been made aware of an organization that seems to be > > pretty actively sending out nastygrams to people who redistribute > > their software which is a QEMU derivative. > > Any insight would be appreciated! I've communicated with the FSF > > and the Software Freedom Conservancy, and they agree that > > hypothetically it is a violation. I just need someone to confirm > > that the contents of that linux binary are QEMU. From the looks of > > it, if this company is filing lawsuits, it puts a MAJOR damper on > > the open source community, so any help is appreciated. Are they sending out nastygrams, or are they filing lawsuits? There's a world of difference between the two. Pretty much anyone can send out nastygrams for any reason. (No doubt there are certain specific things you can can't say -- check with your lawyer.) Filing a lawsuit based on claims you know are bogus is legally actionable. As always, if this really matters to you, talk to a good lawyer. Dale
[Qemu-discuss] Why are qcow2 internal snapshots (savevm and otherwise) still so slow
This is just a burp of frustration, after years of running qemu+kvm. I am currently running qemu-system version 2.1.0 (Debian package 2.1+dfsg-2~bpo70+2), and after several years of ongoing bug reports (and various patches)from others, snapshots are still painfully slow. Even simple snapshot operations take large amounts of time. Creating and removing snapshots from a running VM makes the VM unresponsive (pings etc. fail), often for as much as 30 minutes to an hour. Note that this is happening on a production system, so experimentation is limited and unsafe cache settings are just not an option. In one qemu bug tracker (not sure if it is the current one), I found reports and patches for at least 3 internal issues related to this: 1. Unnecessary disk flushes for each update of each entry in some qcow2 file format tables(I think it was the L1 or L2 tables). It seems that functions intended to perform and flush single allocations are being misused by calling them in a loop for the bulk allocations involved in snapshots. 2. Failure to remove a temporary copy of the savevm memory image from the HEAD of the snapshot tree (not sure why it was written there and not in the snapshot itself). 3. Metadata pre-allocation not surviving snapshot creation/removal. In addition to these bug reports, I have noticed in other documents, that snapshot-related features, such as streaming blocks to combine snapshots are inexplicably designed only to cover non-typical cases in terms of the direction blocks are copied, compared to what is actually needed by the snapshot commands exposed in the user interfaces. There is also a lack of clear rules as to how the qcow2 format handles being backed up while "live" and later restored, then jumped to a snapshot made just before the backup (this is the standard scenario for snapshot-based backups and restores). For instance this may cause the "reference count" fields in a restored file to be out of sync with the referring tables, if one or more blocks were written while the backup program was reading the qcow2 file sequentially. It seems strange that such a basic operation, using the native qemu file format, isn't considered apriority in terms of reliability and performance. P.S. In case you didn't know, the standard way to backup virtual machines (qemu orotherwise) is this sequence: - Create snapshot named "Backup #"using savevm. - Sequentially copy disk image file using a tool such as gnu tar. (Any byte ranges that change due to the running VM may get backed up with their values at any time during this copy operation). - Remove snapshot named "Backup #" After the disaster: - Restore disk image file as it was seen by the backup tool. -Restart virtual machine from the disk image, memory image etc. represented by thesnapshot named "Backup #" (loadvm). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [Qemu-discuss] Re (2): running a system installer under QEMU
> From: pe...@easthope.ca > Debian Wheezy denotes an ATA disk as /dev/sdx. > https://wiki.debian.org/Persistent_disk_names > Likewise for a USB flash store. > > This QEMU assumes my /dev/sda is a SCSI? Certainly a possible explanation. > In my imagination, the Debian port of QEMU recognizes Debian naming > conventions. Perhaps not but a solution using "-disk" will help. QEMU could easily use a different convention than the OS that it is running on because QEMU doesn't use the name to access the OS's file system. QEMU has to decide "Do I present an IDE interface to the simulated CPU, or do I present a SCSI interface?" > From: pe...@easthope.ca > > You can adjust the disk interface that the virtual machine sees by > > using the if= parameter of the -disk option rather than the -hda > > option. > > Google "site:qemu.org -disk" doesn't pan out. "-disk" is a new option > not yet documented? My mistake, it's "drive", although you've already discovered that. Here's a copy of the basic documentation: http://wiki.qemu.org/download/qemu-doc.html > From: pe...@easthope.ca > Is that plausable? Is the "media=disk" suboption necessary? I'm sure that the simulated drive for a "disk" appears to the guest software differently than the simulated drive for a "cdrom". Dale
[Qemu-discuss] qemu hangs on loading Fedora 20 guest
Hello, I launch Qemu in test console: % qemu-system-x86_64 -cpu host -boot c -hda fedora.qcow2 -snapshot -m 1024 --enable-kvm -name vm0 -curses -pidfile /var/run/vm0.pid -net none -netdev type=tap,id=net0,script=no,downscript=no,ifname=vhost0,vhost=on -device virtio-net-pci,netdev=net0 And it starts booting the kernel, I see messages, however it hangs shortly and all I see on the screen is "1280x1024 Graphic mode" in the center. I don't want any graphics, so I even updated grub.cfg on the guest and replaced 'rhgb' with 'text'. Also in the guest: % ls -la /etc/systemd/system/default.target lrwxrwxrwx. 1 root root 37 Sep 22 17:17 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target % What else should I do to run it in purely text mode? Thanks. -- Roman Mashak
