Hi Dominique,
Thank you for your help. I have added the requested XML and created the
missing directory, verifying the permissions and ownership exist for
libvirt-qemu:kvm as all the other directories do. This should allow
libvirt to have write permissions, no?
Here is the error I'm receiving when trying to start the VM (it looks
like a permission issue):
------------------------------------------------------
Error starting domain: internal error: process exited while connecting
to monitor: qemu-system-x86_64: -chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/Windows10.org.qemu.quest_agent.0,server,nowait:
Failed to bind socket: Permission denied
qemu-system-x86_64: -chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/Windows10.org.qemu.quest_agent.0,server,nowait:
chardev: opening backend "socket" failed
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in
tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in
startup
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 866, in
create
if ret == -1: raise libvirtError ('virDomainCreate() failed',
dom=self)
libvirtError: internal error: process exited while connecting to
monitor: qemu-system-x86_64: -chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/Windows10.org.qemu.quest_agent.0,server,nowait:
Failed to bind socket: Permission denied
qemu-system-x86_64: -chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/Windows10.org.qemu.quest_agent.0,server,nowait:
chardev: opening backend "socket" failed
-------------------------------------------------------
Here is the ownership and file permissions for every directory off
of /var/lib/libvirt. I had to create the channel/target/ directory and
sub
------------------------------------------------------
root@Linux-Precision-T1500:/# tree -dugp /var/lib/libvirt
/var/lib/libvirt
├── [drwx--x--x root root ] boot
├── [drwxr-xr-x root root ] dnsmasq
├── [drwx--x--x root root ] images
├── [drwxr-xr-x root root ] network
├── [drwxr-x--- libvirt- kvm ] qemu
│ ├── [drwxr-xr-x libvirt- kvm ] channel
│ │ └── [drwxr-xr-x libvirt- kvm ] target
│ ├── [drwxr-xr-x root root ] dump
│ ├── [drwxr-xr-x libvirt- kvm ] save
│ └── [drwxr-xr-x libvirt- kvm ] snapshot
└── [drwx------ root root ] sanlock
----------------------------------------------------
... did I miss something?
Thank you in advance.
Kind regards,
-Frank
-----Original Message-----
From: Dominique Ramaekers <dominique.ramaek...@cometal.be>
To: Frank Sfalanga Jr. <fr...@csiglobalvcard.com>
Cc: qemu-discuss@nongnu.org <qemu-discuss@nongnu.org>
Subject: RE: [problem] QEMU-GA & Windows 10
Date: Sun, 24 Jul 2016 13:32:39 +0000
> -----Oorspronkelijk bericht-----
> Van: Frank Sfalanga Jr. [mailto:fr...@csiglobalvcard.com]
> Verzonden: maandag 18 juli 2016 20:16
> Aan: Dominique Ramaekers
> CC: qemu-discuss@nongnu.org
> Onderwerp: Re: [problem] QEMU-GA & Windows 10
>
> Hi Dominique,
>
> Just returned from my trip. Thank you for your patience. As requested, here
> is a copy of the XML for this VM on the host:
>
> <domain type='kvm'>
> <name>Windows10</name>
> <uuid>b69f4f7e-84db-faf5-0f93-9b14babdba78</uuid>
....
#Add in the xml before the closing tag </devices>:
<channel type='unix'>
<target type='virtio' name='org.qemu.quest_agent.0' state='connected' />
</channel>
After saving, look into the xml again. If all is right, libvirt added some
extra lines. One of the lines
has a path (ex.
path='/var/lib/libvirt/qemu/channel/target/domain-XXXXX/org.qemu.guest_agent.0').
Check if the path (until the folder domain-XXXXX) exists and libvirt can write
to it. If not, create it
yourselves and apply the correct rights.
Also look at the 'address' part. The combination type+controller+bus+port
should be unique in
your xml. If not, change the port to a free port of that bus.
....
> </devices>
> </domain>
...
> Thank you in advance for any direction you can provide.
>
> Kind regards,
>
> -Frank
Make shure you have shutdown the guest.
Start the guest again.
If all is right, the guest agent should start on startup.
Note: it's not necessary QEMU GUEST AGENT VSS PROVIDER is started.
The guest agent will start the VSS Provider if needed.
It can't hurt neither, it will stop automatically when it wants to...
Hope this helps...
> -----Original Message-----
> From: Dominique Ramaekers <dominique.ramaek...@cometal.be>
> To: Frank Sfalanga Jr. <fr...@csiglobalvcard.com>, qemu-
> disc...@nongnu.org <qemu-discuss@nongnu.org>
> Subject: RE: [problem] QEMU-GA & Windows 10
> Date: Thu, 14 Jul 2016 09:30:33 +0000
>
>
> > -----Oorspronkelijk bericht-----
> > Van: Qemu-discuss [mailto:qemu-discuss-
> > bounces+dominique.ramaekers=cometal...@nongnu.org] Namens Frank
> > Sfalanga Jr.
> > Verzonden: dinsdag 12 juli 2016 19:31
> > Aan: qemu-discuss@nongnu.org
> > Onderwerp: [Qemu-discuss] [problem] QEMU-GA & Windows 10
> >
> > Hello,
> >
> > Ubuntu 14.04LTS
> > KVM/Qemu
> >
> > After a bit of struggle I was recently able to get Windows 10 running
> > in a VM with kvm/qemu. I have the virtio drivers installed and have
> > converted the disk to the .qcow2 file system.
> >
> > The last piece of the puzzle is getting the QEMU GUEST AGENT working.
> > I've googled around and found reports of people successfully upgrading
> > Windows 7 to Windows 10 but cannot find any reports of success using
> > qemu guest agent with a Windows 10 clean install.
>
> I've done it with little trouble.
>
> >
> > My issue specifically is that the QEMU GUEST AGENT VSS PROVIDER will
> > start if I do it manually, the GUEST AGENT itself will not, ever. I
> > receive the following error:
> >
> > ----------------------------
> > ERROR 1053: The service did not respond to the start or control
> > request in a timely fashion.
> > ----------------------------
> >
>
> Please post the xml of the guest...
>
> You should be able to find something like this in the xml:
> <channel type='unix'>
> <source mode='bind'
> path='/var/lib/libvirt/qemu/channel/target/domain-
> PCVIRTdra/org.qemu.guest_agent.0'/>
> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
> <alias name='channel0'/>
> <address type='virtio-serial' controller='0' bus='0' port='2'/>
> </channel>
>
> If not, please make sure the location for the channel exist and has the
> correct access rights:
>
> root@CmsrvVH3:~# ls -lh /var/lib/libvirt/qemu/channel totaal 4,0K drwxr-
> xr-x 10 libvirt-qemu kvm 4,0K jul 1 08:57 target
>
> > Hopefully there is a fix, or you can point me to the correct mailing
> > list if this is not it.
> >
> > Thank you in advance.
> >
> > Kind regards,
> >
> > -Frank
> >
>
> Sorry about the late reply...
>
>
> --
> Frank Sfalanga Jr | Director, Information Technology & Application Services
> Ph. 239-221-3309 | fr...@csiglobalvcard.com
> 3301 Bonita Beach Road #300 | Bonita Springs | FL | 34134 Celebrating 25
> years of corporate payment innovation
>
>
>
>
> This message and any attachments are intended solely for the use of the
> intended recipient(s) and may contain information that is privileged,
> confidential or proprietary of CSI Enterprises, Inc. If you are not an
> intended
> recipient, please notify the sender, and then please delete and destroy all
> copies and attachments, and be advised that any review or dissemination
> of, or the taking of any action in reliance on, the information contained in
> or
> attached to this message is prohibited.
>
>
>
--
Frank Sfalanga Jr | Director, Information Technology & Application
Services
Ph. 239-221-3309 | fr...@csiglobalvcard.com
3301 Bonita Beach Road #300 | Bonita Springs | FL | 34134
Celebrating 25 years of corporate payment innovation
This message and any attachments are intended solely for the use of the
intended recipient(s) and may contain information that is privileged,
confidential or proprietary of CSI Enterprises, Inc. If you are not an
intended recipient, please notify the sender, and then please delete and
destroy all copies and attachments, and be advised that any review or
dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
