Re: [virt-tools-list] [virt-manager PATCH 0/2] some follow-up patches for virt-clone

[Cole Robinson]

On 11/03/2015 05:57 AM, Pavel Hrdina wrote:
> Pavel Hrdina (2):
>   virt-clone: fix pylint error
>   tests: introduce a test for removing unix channel path for virt-clone
> 
>  tests/cli-test-xml/compare/virt-clone-clone-auto1.xml | 5 +
>  tests/testdriver.xml  | 4 
>  virtinst/cloner.py| 2 +-
>  3 files changed, 10 insertions(+), 1 deletion(-)
> 

ACK series

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] virt-install: always enable pae for xen hvm 64bit guest

[Cole Robinson]

On 11/03/2015 07:15 AM, Pavel Hrdina wrote:
> According to xen documentation 64bit guest has to have pae enabled in
> order to be able to run 64bit OS.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1267160
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  tests/cli-test-xml/compare/virt-install-xen-hvm.xml | 1 +
>  virtinst/guest.py   | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-xen-hvm.xml 
> b/tests/cli-test-xml/compare/virt-install-xen-hvm.xml
> index 41f03c0..746cce8 100644
> --- a/tests/cli-test-xml/compare/virt-install-xen-hvm.xml
> +++ b/tests/cli-test-xml/compare/virt-install-xen-hvm.xml
> @@ -13,6 +13,7 @@
>
>  
>  
> +
>
>
>destroy
> diff --git a/virtinst/guest.py b/virtinst/guest.py
> index 6f2b30a..ec66f7a 100644
> --- a/virtinst/guest.py
> +++ b/virtinst/guest.py
> @@ -881,7 +881,12 @@ class Guest(XMLBuilder):
>  if self.features.apic == "default":
>  self.features.apic = self.capsinfo.guest.supports_apic()
>  if self.features.pae == "default":
> -self.features.pae = self.capsinfo.guest.supports_pae()
> +if (self.os.is_hvm() and
> +self.type == "xen" and
> +self.os.arch == "x86_64"):
> +self.features.pae = True
> +else:
> +self.features.pae = self.capsinfo.guest.supports_pae()
>  
>  if (self.features.vmport == "default" and
>  self.os.is_x86() and
> 

ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 3/3] Modify the machine type for s390x.All machine types begin with "s390x-ccw" will by set to the default machine type "s390-ccw-virtio".

[Cole Robinson]

On 11/04/2015 01:30 AM, Kevin Zhao wrote:
> ---
>  virtinst/capabilities.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virtinst/capabilities.py b/virtinst/capabilities.py
> index 4fa1724..10e7ea0 100644
> --- a/virtinst/capabilities.py
> +++ b/virtinst/capabilities.py
> @@ -364,7 +364,7 @@ class _CapsInfo(object):
>  return "vexpress-a15"
>  
>  if self.arch in ["s390x"]:
> -if "s390-ccw-virtio" in self.machines:
> +if any(machine.startswith("s390-ccw") for machine in 
> self.machines):
>  return "s390-ccw-virtio"
>  
>  return None
> 

Is this still needed? The capabilities XML you added to the test suite has the
proper s390-ccw-virtio mapping value... why do we need to check for the
s390-ccw prefix, and not the actual value we are going to specify in the XML?

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 1/3] Add a capatilities-xml for s390x, and add a clitest for it.

[Cole Robinson]

On 11/04/2015 01:30 AM, Kevin Zhao wrote:
> Add a capatilities xml file for s390x ,the capatility for IBM
> Distro called KVMIBM,mainly focus on a KVM hypervious on S390x.
> Also add a clitest by using virt-install.
> ---
>  tests/capabilities-xml/kvm-s390x-KVMIBM.xml| 82 
> ++
>  .../compare/virt-install-s390x-KVMIBM.xml  | 39 ++
>  tests/clitest.py   |  1 +
>  tests/utils.py |  1 +
>  4 files changed, 123 insertions(+)
>  create mode 100644 tests/capabilities-xml/kvm-s390x-KVMIBM.xml
>  create mode 100644 tests/cli-test-xml/compare/virt-install-s390x-KVMIBM.xml
> 
> diff --git a/tests/capabilities-xml/kvm-s390x-KVMIBM.xml 
> b/tests/capabilities-xml/kvm-s390x-KVMIBM.xml
> new file mode 100644
> index 000..171266d
> --- /dev/null
> +++ b/tests/capabilities-xml/kvm-s390x-KVMIBM.xml
> @@ -0,0 +1,82 @@
> +# The xml comes from the Distro KVMIBM for s390x

This is not a valid XML comment. It needs to be



> +
> +
> +  
> +b53b15d6-348a-4620-afd3-81278b81fbd7
> +
> +  s390x
> +  host
> +  
> +  
> +  
> +
> +
> +  
> +  
> +
> +
> +  
> +  
> +tcp
> +rdma
> +  
> +
> +
> +  
> +
> +  3911020
> +  
> +
> +
> +
> +
> +  
> +
> +  
> +
> +
> +  selinux
> +  0
> +  system_u:system_r:svirt_t:s0
> +  system_u:system_r:svirt_tcg_t:s0
> +
> +
> +  dac
> +  0
> +  +107:+107
> +  +107:+107
> +
> +  
> +
> +  
> +hvm
> +
> +  64
> +  /usr/bin/qemu-system-s390x
> +  s390-ccw-kvmibm-1.1.1
> +   maxCpus="64">s390-ccw-virtio
> +  s390-ccw-kvmibm-1.1.0
> +  s390-virtio
> +  s390
> +  s390-ccw-virtio-2.4
> +  
> +/usr/bin/qemu-system-s390x
> +  
> +  
> +/usr/bin/qemu-kvm
> +s390-ccw-kvmibm-1.1.1
> + maxCpus="64">s390-ccw-virtio
> +s390-ccw-kvmibm-1.1.0
> +s390-virtio
> +s390
> +s390-ccw-virtio-2.4
> +  
> +
> +
> +  
> +  
> +  
> +
> +  
> +
> +
> diff --git a/tests/cli-test-xml/compare/virt-install-s390x-KVMIBM.xml 
> b/tests/cli-test-xml/compare/virt-install-s390x-KVMIBM.xml
> new file mode 100644
> index 000..081c45d
> --- /dev/null
> +++ b/tests/cli-test-xml/compare/virt-install-s390x-KVMIBM.xml
> @@ -0,0 +1,39 @@
> +
> +  foobar
> +  ----
> +  65536
> +  65536
> +  1
> +  
> +hvm
> +/kernel.img
> +/initrd.img
> +  
> +  
> +  destroy
> +  restart
> +  restart
> +  
> +/usr/bin/qemu-kvm
> +
> +  
> +  
> +  
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +  
> +  
> +
> +
> +
> +  
> +  
> +
> +  
> +
> \ No newline at end of file
> diff --git a/tests/clitest.py b/tests/clitest.py
> index 7b4ebd4..6100fc2 100644
> --- a/tests/clitest.py
> +++ b/tests/clitest.py
> @@ -704,6 +704,7 @@ c.add_compare("--connect %(URI-KVM-PPC64LE)s --import 
> --disk %(EXISTIMG1)s --os-
>  
>  # s390x tests
>  c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21", 
> "s390x-cdrom")
> +c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21", 
> "s390x-cdrom-KVMIBM")
>  
>  # qemu:///session tests
>  c.add_compare("--connect %(URI-KVM-SESSION)s --disk size=8 --os-variant 
> fedora21 --cdrom %(EXISTIMG1)s", "kvm-session-defaults")
> diff --git a/tests/utils.py b/tests/utils.py
> index 748e808..2db01ee 100644
> --- a/tests/utils.py
> +++ b/tests/utils.py
> @@ -49,6 +49,7 @@ uri_kvm_armv7l = (_uri_kvm_domcaps + _capsprefix + 
> "kvm-armv7l.xml")
>  uri_kvm_aarch64 = (_uri_kvm_domcaps + _capsprefix + "kvm-aarch64.xml")
>  uri_kvm_ppc64le = (_uri_kvm_domcaps + _capsprefix + "kvm-ppc64le.xml")
>  uri_kvm_s390x = (_uri_kvm_domcaps + _capsprefix + "kvm-s390x.xml")
> +uri_kvm_s390x-KVMIBM = (_uri_kvm_domcaps + _capsprefix + 
> "kvm-s390x-KVMIBM.xml")
>  

This doesn't even work... you can't have a hyphen in a python variable name.
Please test your patches after making changes

I fixed these issues and pushed patch 1 + 2

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 3/3] Modify the machine type for s390x.All machine types begin with "s390x-ccw" will by set to the default machine type "s390-ccw-virtio".

[Cole Robinson]

On 11/04/2015 10:12 PM, Kevin Zhao wrote:
> Hi Cole ,
> Thanks for merging my patch.
> I choose to check for the prefix because that the next version of KVMIBM may
> change the machine type,they are not always have the machine type
> "s390-ccw-virtio ", so I preserve the checking for the machine type.
> 

So KVMIBM doesn't advertise a s390-ccw-virtio machine type, but it accepts it?
Then that's a bug on their side, or in the libvirt handling. Tools should
never have to know some magic machine type that isn't advertised in the
libvirt capabilities XML. So I think you fix this on the KVMIBM side

- Cole

> On 2015年11月05日 03:53, Cole Robinson wrote:
>> On 11/04/2015 01:30 AM, Kevin Zhao wrote:
>>> a5a467fddcb8---
>>>   virtinst/capabilities.py | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/virtinst/capabilities.py b/virtinst/capabilities.py
>>> index 4fa1724..10e7ea0 100644
>>> --- a/virtinst/capabilities.py
>>> +++ b/virtinst/capabilities.py
>>> @@ -364,7 +364,7 @@ class _CapsInfo(object):
>>>   return "vexpress-a15"
>>> if self.arch in ["s390x"]:
>>> -if "s390-ccw-virtio" in self.machines:
>>> +if any(machine.startswith("s390-ccw") for machine in
>>> self.machines):
>>>   return "s390-ccw-virtio"
>>> return None
>>>
>> Is this still needed? The capabilities XML you added to the test suite has 
>> the
>> proper s390-ccw-virtio mapping value... why do we need to check for the
>> s390-ccw prefix, and not the actual value we are going to specify in the XML?
>>
>> - Cole
>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] virtinst.connection: detect RHEL system also for session connection

[Cole Robinson]

On 11/05/2015 07:54 AM, Pavel Hrdina wrote:
> We should detect RHEL qemu also for session connection, not only system
> connection, the capabilities of both are the same.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1258691
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> I'm not sure, why there was only qemu_system, I've tried to follow the change 
> to
> its origin, but it didn't help.
> 

I don't think there's any good reason TBH

ACK

- Cole

>  virtinst/connection.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virtinst/connection.py b/virtinst/connection.py
> index aef7b48..a09f4df 100644
> --- a/virtinst/connection.py
> +++ b/virtinst/connection.py
> @@ -326,7 +326,7 @@ class VirtualConnection(object):
>  if not CLIConfig.stable_defaults and not force:
>  return False
>  
> -if not self.is_qemu_system():
> +if not self.is_qemu():
>  return False
>  
>  if emulator:
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] possible bug in passing host cpu configuration

[Cole Robinson]

On 11/08/2015 10:37 AM, LK wrote:
> Hi,
> 
> I have banged my head for a few days on a problem with a virtual machine
> configuration.
> 
> I want to use Nested Virtualization, but virt-manager did not let me to pass
> the host cpu configuration (I checked the "Copy host CPU configuration").
> 
> After countless tests I was giving up (I also tried to modify manually the xml
> file in /etc/libvirt/qemu/vm.xml), but as last attempt I discarded
> virt-manager and used virsh instead.
> 
> I modified the configuration of the VM (virsh edit vm) and added this cpu
> configuration:
> 
> ###
> 
> 
> ###
> 
> I saved the configuration and launched the VM and finally the guest operating
> system (proxmox4) shows me that it can use the nested virtualization.
> 
> I'm using as host Fedora 23 x86_64 and virt-manager  1.2.1.
> 
> The funny thing is that after configuring the VM using virsh edit, now
> virt-manager retain the correct configuration.
> 

Yes, for some reason mode=host-model isn't sufficient for virt passthrough on
some machines. We don't expose host-passthrough in the UI because it's not
generally recommended for libvirt usage since we can't insulate the VM from
qemu logic changes. But you can specify it in the UI by manually entering
host-passthrough in the CPU model field

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] possible bug in passing host cpu configuration

[Cole Robinson]

On 11/08/2015 06:32 PM, Cole Robinson wrote:
> On 11/08/2015 10:37 AM, LK wrote:
>> Hi,
>>
>> I have banged my head for a few days on a problem with a virtual machine
>> configuration.
>>
>> I want to use Nested Virtualization, but virt-manager did not let me to pass
>> the host cpu configuration (I checked the "Copy host CPU configuration").
>>
>> After countless tests I was giving up (I also tried to modify manually the 
>> xml
>> file in /etc/libvirt/qemu/vm.xml), but as last attempt I discarded
>> virt-manager and used virsh instead.
>>
>> I modified the configuration of the VM (virsh edit vm) and added this cpu
>> configuration:
>>
>> ###
>> 
>> 
>> ###
>>
>> I saved the configuration and launched the VM and finally the guest operating
>> system (proxmox4) shows me that it can use the nested virtualization.
>>
>> I'm using as host Fedora 23 x86_64 and virt-manager  1.2.1.
>>
>> The funny thing is that after configuring the VM using virsh edit, now
>> virt-manager retain the correct configuration.
>>
> 
> Yes, for some reason mode=host-model isn't sufficient for virt passthrough on
> some machines. We don't expose host-passthrough in the UI because it's not
> generally recommended for libvirt usage since we can't insulate the VM from
> qemu logic changes. But you can specify it in the UI by manually entering
> host-passthrough in the CPU model field
> 

This virt-manager bug has links to other issues detailing the problems with
libvirt's host-model:

https://bugzilla.redhat.com/show_bug.cgi?id=1055002

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Add a watchdog model diag288, listed in the watchdog model list.

[Cole Robinson]

On 11/06/2015 01:25 AM, Kevin Zhao wrote:
> Since the qemu 2.4 has supported the watchdog device diag288
> for s390x,so add it in the optional model list. Also modefied
> the clitest xml to cover this change.
> ---
>  tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml | 1 +
>  virtinst/devicewatchdog.py | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml 
> b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> index b9f057c..3cccaca 100644
> --- a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> +++ b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> @@ -31,5 +31,6 @@
>
>  
>  
> +
>
>  

You've added this XML, but no corresponding change in clitest.py, so this
breaks the test suite.

- Cole

> diff --git a/virtinst/devicewatchdog.py b/virtinst/devicewatchdog.py
> index 17c3e57..7bb9002 100644
> --- a/virtinst/devicewatchdog.py
> +++ b/virtinst/devicewatchdog.py
> @@ -27,8 +27,9 @@ class VirtualWatchdog(VirtualDevice):
>  
>  MODEL_I6300 = "i6300esb"
>  MODEL_IB700 = "ib700"
> +MODEL_DIAG288 = "diag288"
>  MODEL_DEFAULT = "default"
> -MODELS = [MODEL_I6300, MODEL_IB700]
> +MODELS = [MODEL_I6300, MODEL_IB700, MODEL_DIAG288]
>  
>  ACTION_SHUTDOWN = "shutdown"
>  ACTION_RESET= "reset"
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Add a watchdog model diag288, listed in the watchdog model list.

[Cole Robinson]

On 11/08/2015 09:57 PM, Kevin Zhao wrote:
> Since the qemu 2.4 has supported the watchdog device diag288
> for s390x,so add it in the optional model list. Also modefied
> the clitest xml to cover this change.
> ---
>  tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml | 1 +
>  tests/clitest.py   | 2 +-
>  virtinst/devicewatchdog.py | 3 ++-
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml 
> b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> index b9f057c..3cccaca 100644
> --- a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> +++ b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> @@ -31,5 +31,6 @@
>
>  
>  
> +
>
>  
> diff --git a/tests/clitest.py b/tests/clitest.py
> index f4ce381..c3180f6 100644
> --- a/tests/clitest.py
> +++ b/tests/clitest.py
> @@ -705,7 +705,7 @@ c.add_compare("--connect %(URI-KVM-PPC64LE)s --import 
> --disk %(EXISTIMG1)s --os-
>  
>  # s390x tests
>  c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21", 
> "s390x-cdrom")
> -c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X-KVMIBM)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21", 
> "s390x-cdrom-KVMIBM")
> +c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X-KVMIBM)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21 
> --watchdog diag288,action=reset", "s390x-cdrom-KVMIBM")
>  
>  # qemu:///session tests
>  c.add_compare("--connect %(URI-KVM-SESSION)s --disk size=8 --os-variant 
> fedora21 --cdrom %(EXISTIMG1)s", "kvm-session-defaults")
> diff --git a/virtinst/devicewatchdog.py b/virtinst/devicewatchdog.py
> index 17c3e57..7bb9002 100644
> --- a/virtinst/devicewatchdog.py
> +++ b/virtinst/devicewatchdog.py
> @@ -27,8 +27,9 @@ class VirtualWatchdog(VirtualDevice):
>  
>  MODEL_I6300 = "i6300esb"
>  MODEL_IB700 = "ib700"
> +MODEL_DIAG288 = "diag288"
>  MODEL_DEFAULT = "default"
> -MODELS = [MODEL_I6300, MODEL_IB700]
> +MODELS = [MODEL_I6300, MODEL_IB700, MODEL_DIAG288]
>  
>  ACTION_SHUTDOWN = "shutdown"
>  ACTION_RESET= "reset"
> 

Thanks, pushed now

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] virt-install: don't report missing console in extra-args for ppc64

[Cole Robinson]

On 11/09/2015 02:02 PM, Pavel Hrdina wrote:
> Kernel for ppc64 automatically enables serial console, there is no need
> to report any warning.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1247434
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Pushed as trivial.
> 
>  virt-install | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/virt-install b/virt-install
> index d509256..3656835 100755
> --- a/virt-install
> +++ b/virt-install
> @@ -520,6 +520,8 @@ def _show_nographics_warnings(options, guest):
>  console_type = serial_arm_arg
>  if guest.get_devices("console")[0].target_type in ["virtio", "xen"]:
>  console_type = hvc_arg
> +if guest.os.is_ppc64():
> +return
>  
>  if console_type in (options.extra_args or ""):
>  return
> 

I don't think this actually works as you expect, this check is done _after_
the warning mentioned in the bug report. I think it should be moved near the
top of the function, where the similar arm machvirt check is done

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] ui: improve pause/resume tooltip

[Cole Robinson]

On 11/09/2015 02:06 PM, Pavel Hrdina wrote:
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238618
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  ui/details.ui | 2 +-
>  ui/manager.ui | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ui/details.ui b/ui/details.ui
> index 6edc0e4..99718d2 100644
> --- a/ui/details.ui
> +++ b/ui/details.ui
> @@ -464,7 +464,7 @@
>
>  True
>  False
> -Pause 
> the virtual machine
> + translatable="yes">Pause/resume the virtual machine
>   translatable="yes">Pause
>  True
>  gtk-media-pause
> diff --git a/ui/manager.ui b/ui/manager.ui
> index 2f3d465..63a4794 100644
> --- a/ui/manager.ui
> +++ b/ui/manager.ui
> @@ -340,7 +340,7 @@
>  True
>  False
>  True
> -Pause 
> the virtual machine
> + translatable="yes">Pause/resume the virtual machine
>   translatable="yes">_Pause
>  True
>  gtk-media-pause
> 

It's a bit more work, but I prefer this done in the code, so a different
tooltip is set depending on if the VM is paused or not.
details.py:refresh_vm_state and manager.py:update_current_selection

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] details: show Channel label by device type

[Cole Robinson]

On 11/10/2015 09:01 AM, Chen Hanxiao wrote:
> From: Chen Hanxiao 
> 
> Currently we show channel label by its name.
> If we use name com.redhat.spice.0 but set it
> as unix socket, the label in details keep unchanged.
> 
> This patch will set label according to device type.
> 

But this loses the nice spice/qemu channel labeling for the common case with
the default virt-manager channels. IMO this change doesn't improve things

- Cole

> Signed-off-by: Chen Hanxiao 
> ---
>  virtManager/details.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virtManager/details.py b/virtManager/details.py
> index 742448d..b1f2662 100644
> --- a/virtManager/details.py
> +++ b/virtManager/details.py
> @@ -213,7 +213,7 @@ def _label_for_device(dev):
>  
>  if devtype == "channel":
>  label = _("Channel")
> -name = dev.pretty_channel_name(dev.target_name)
> +name = dev.pretty_type(dev.type)
>  if name:
>  label += " %s" % name
>  return label
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] virt-install: refresh storage pool after disk is created

[Cole Robinson]

On 11/10/2015 08:19 AM, Pavel Hrdina wrote:
> This fixes an issue where you need to manually refresh storage pool or
> restart virt-manager in order to be able delete guest that is currently
> installed.  This affect remote connection and non-root users.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251400
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  virtinst/storage.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/virtinst/storage.py b/virtinst/storage.py
> index e50b78f..21d21a6 100644
> --- a/virtinst/storage.py
> +++ b/virtinst/storage.py
> @@ -797,6 +797,8 @@ class StorageVolume(_StorageObject):
>  logging.debug("Using vol create flags=%s", createflags)
>  vol = self.pool.createXML(xml, createflags)
>  
> +self.pool.refresh()
> +
>  self._install_finished = True
>  t.join()
>  meter.end(self.capacity)
> 

I don't think this patch actually fixes the reported issue... it doesn't do
anything for me at least.

The root problem here is that libvirt doesn't support event APIs for storage
operations, and virt-manager no longer relentlessly polls the storage list
since it sucks for high latency connections. The disk image is created behind
virt-managers back, and nothing in virt-manager is catching that it's updated.

Particularly the pool.refresh() call here isn't going to signal virt-manager
in any way to update its internal pool/vol cache, so it won't be reflected in
the app.

We already have some hacks in place to deal with outdated cache in
virt-manager, like we will request a pool/vol cache update when launching the
new VM wizard. But in this particular case I don't think it's important enough
to try and fix, we should just defer it until libvirt has storage event APIs.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager v2] details: show Channel label by device type

[Cole Robinson]

On 11/11/2015 07:26 AM, Chen Hanxiao wrote:
> From: Chen Hanxiao 
> 
> Currently we show channel label by its name.
> If we use name com.redhat.spice.0 but set it
> as unix socket, the label in details keep unchanged.
> 
> This patch will set label according to device type
> if we failed matching target_name
> 
> Signed-off-by: Chen Hanxiao 
> ---
> v2: use device type when failed to match target name.
> 
>  virtManager/details.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/virtManager/details.py b/virtManager/details.py
> index 71ba39d..d0e8dc8 100644
> --- a/virtManager/details.py
> +++ b/virtManager/details.py
> @@ -214,6 +214,8 @@ def _label_for_device(dev):
>  if devtype == "channel":
>  label = _("Channel")
>  name = dev.pretty_channel_name(dev.target_name)
> +if not name:
> +name = dev.pretty_type(dev.type)
>  if name:
>  label += " %s" % name
>  return label
> 

Ah okay that looks fine, ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] virt-install: don't report missing console in extra-args for ppc64

[Cole Robinson]

On 11/11/2015 08:17 AM, Pavel Hrdina wrote:
> On Tue, Nov 10, 2015 at 04:20:51PM -0500, Cole Robinson wrote:
>> On 11/09/2015 02:02 PM, Pavel Hrdina wrote:
>>> Kernel for ppc64 automatically enables serial console, there is no need
>>> to report any warning.
>>>
>>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1247434
>>>
>>> Signed-off-by: Pavel Hrdina 
>>> ---
>>>
>>> Pushed as trivial.
>>>
>>>  virt-install | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/virt-install b/virt-install
>>> index d509256..3656835 100755
>>> --- a/virt-install
>>> +++ b/virt-install
>>> @@ -520,6 +520,8 @@ def _show_nographics_warnings(options, guest):
>>>  console_type = serial_arm_arg
>>>  if guest.get_devices("console")[0].target_type in ["virtio", "xen"]:
>>>  console_type = hvc_arg
>>> +if guest.os.is_ppc64():
>>> +return
>>>  
>>>  if console_type in (options.extra_args or ""):
>>>  return
>>>
>>
>> I don't think this actually works as you expect, this check is done _after_
>> the warning mentioned in the bug report. I think it should be moved near the
>> top of the function, where the similar arm machvirt check is done
>>
>> - Cole
> 
> It works as I expected, the warning mentioned in the BZ was updated by
> commit 601a82cb.  I don't want to return near the top of the function where is
> that check for arm, because there is still another warning about "No --console
> device added, ..." which should be printed if user explicitly disable console
> for his guest using "--console none".
> 

You're right, my mistake! Misread the error message in the bug report.

ACK to this, but it means I need to fix the arm check as well

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Questions about cdrom installation in virt-manager

[Cole Robinson]

On 11/11/2015 12:45 AM, Kevin Zhao wrote:
> Hi Cole & all,
>   There is a question just confusing me.
>   When I use virt-install , set the  --location parameter like this : 
> --location /tmp/**.iso, virt-install can search the iso and get the tree.info
> , kernel.img and initrd.img. But when I replace the parameter "--location "
> with the "--cdrom", it will not be able to search the iso for kernel.img and
> initrd.img ,I need to specify the kernel and initrd(Maybe inn the arch ppc64le
> and s390x).
>But when I use virt-manager, choose the cdrom I can not get the
> functions just like "--location". So does the virt-manager support the
> functions just like "--location" do? I see that by using network installation
> , virt-manager will search for tree.info, how to use  it  to get a local iso
> treeinfo?
>My descriptions may not be very clear . So feel free to let me know if
> you have any question.
> 

The difference between --location $ISO and --cdrom $ISO are kinda subtle:

--cdrom $ISO just passes the $ISO as a cdrom device to the guest

--location $ISO tries to mount the $ISO locally, and treat that local path
like a --location $URL install, pulling out the kernel/initrd. This allows
passing in custom kernel args, but is kinda limited since you need root access
to mount the iso

You can actually trigger this with virt-manager by entering a local ISO path
into the install URL field

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH 1/2] virt-install: warn user about missing console while installing on arm

[Cole Robinson]

On 11/11/2015 03:32 PM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Pushed as trivial.
> 
>  virt-install | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/virt-install b/virt-install
> index 3656835..e465c46 100755
> --- a/virt-install
> +++ b/virt-install
> @@ -488,10 +488,6 @@ def _show_nographics_warnings(options, guest):
>  return
>  if not options.autoconsole:
>  return
> -if guest.os.is_arm_machvirt():
> -# Later arm kernels figure out console= automatically, so don't
> -# warn about it.
> -return
>  
>  if guest.installer.cdrom:
>  logging.warn(_("CDROM media does not print to the text console "
> @@ -520,7 +516,9 @@ def _show_nographics_warnings(options, guest):
>  console_type = serial_arm_arg
>  if guest.get_devices("console")[0].target_type in ["virtio", "xen"]:
>  console_type = hvc_arg
> -if guest.os.is_ppc64():
> +if guest.os.is_ppc64() or guest.os.is_arm_machvirt():
> +# Later arm/ppc kernels figure out console= automatically, so don't
> +# warn about it.
>  return
>  
>  if console_type in (options.extra_args or ""):
> 

ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH 2/2] virt-install: fix condition that detect if console is present

[Cole Robinson]

On 11/11/2015 03:32 PM, Pavel Hrdina wrote:
> Function get_devices() always returns a list, if there is no requested
> device the list is empty.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Pushed as trivial.
> 
>  virt-install | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virt-install b/virt-install
> index e465c46..c5c6e57 100755
> --- a/virt-install
> +++ b/virt-install
> @@ -502,7 +502,7 @@ def _show_nographics_warnings(options, guest):
>  # Trying --location --nographics with console connect. Warn if
>  # they likely won't see any output.
>  
> -if not guest.get_devices("console"):
> +if len(guest.get_devices("console")) = 0:
>  logging.warn(_("No --console device added, you likely will not "
>  "see text install output from the guest."))
>  return
> 

Does this actually make a difference? 'not []' returns True after all...

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH 2/2] virt-install: fix condition that detect if console is present

[Cole Robinson]

On 11/11/2015 04:01 PM, Pavel Hrdina wrote:
> On Wed, Nov 11, 2015 at 03:50:30PM -0500, Cole Robinson wrote:
>> On 11/11/2015 03:32 PM, Pavel Hrdina wrote:
>>> Function get_devices() always returns a list, if there is no requested
>>> device the list is empty.
>>>
>>> Signed-off-by: Pavel Hrdina 
>>> ---
>>>
>>> Pushed as trivial.
>>>
>>>  virt-install | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/virt-install b/virt-install
>>> index e465c46..c5c6e57 100755
>>> --- a/virt-install
>>> +++ b/virt-install
>>> @@ -502,7 +502,7 @@ def _show_nographics_warnings(options, guest):
>>>  # Trying --location --nographics with console connect. Warn if
>>>  # they likely won't see any output.
>>>  
>>> -if not guest.get_devices("console"):
>>> +if len(guest.get_devices("console")) = 0:
>>>  logging.warn(_("No --console device added, you likely will not "
>>>  "see text install output from the guest."))
>>>  return
>>>
>>
>> Does this actually make a difference? 'not []' returns True after all...
>>
>> - Cole
> 
> Hm, that's true, I wonder, why I didn't saw that warning before.  I've pushed 
> it
> already, so should we leave it as it is or revert this patch?
> 

It's minor but I'd suggest reverting it, so that the git history indicates
it's not a bug fix. I don't want to be scratching my head 6 months from now
wondering if this actually fixed something, because I'll probably forget this
conversation :)

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH v2] ui: improve pause/resume tooltip

[Cole Robinson]

On 11/12/2015 07:14 AM, Pavel Hrdina wrote:
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238618
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  virtManager/details.py | 6 ++
>  virtManager/manager.py | 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/virtManager/details.py b/virtManager/details.py
> index 71ba39d..617235d 100644
> --- a/virtManager/details.py
> +++ b/virtManager/details.py
> @@ -1301,6 +1301,12 @@ class vmmDetails(vmmGObjectUI):
>  self.widget("control-shutdown").get_menu().update_widget_states(vm)
>  self.widget("control-pause").set_sensitive(stop)
>  
> +if paused:
> +pauseTooltip = _("Resume the virtual machine")
> +else:
> +pauseTooltip = _("Pause the virtual machine")
> +self.widget("control-pause").set_tooltip_text(pauseTooltip)
> +
>  self.widget("details-vm-menu").get_submenu().update_widget_states(vm)
>  self.set_pause_state(paused)
>  
> diff --git a/virtManager/manager.py b/virtManager/manager.py
> index 79cf0c5..edc29c7 100644
> --- a/virtManager/manager.py
> +++ b/virtManager/manager.py
> @@ -870,6 +870,12 @@ class vmmManager(vmmGObjectUI):
>  self.set_pause_state(is_paused)
>  self.widget("vm-pause").set_sensitive(show_pause)
>  
> +if is_paused:
> +pauseTooltip = _("Resume the virtual machine")
> +else:
> +pauseTooltip = _("Pause the virtual machine")
> +self.widget("vm-pause").set_tooltip_text(pauseTooltip)
> +
>  self.widget("menu_edit_details").set_sensitive(show_details)
>  self.widget("menu_host_details").set_sensitive(host_details)
>  
> 

ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Questions about cdrom installation in virt-manager

[Cole Robinson]

When I tried it, I just entered the path like: /path/to/media.iso

If virt-manager doesn't find it in /var/lib/libvirt/images, it could be that
either the default pool needs to be refreshed, or if you are running as
non-root then maybe the app is getting confused because it can't manually
access /var/lib/libvirt/images. --debug info might have more hints. Remember
like I said below this will only work with virt-manager if you run as root

- Cole

On 11/12/2015 07:24 PM, Kevin Zhao wrote:
> Hi Cole,
> Sorry to disturb you. Firstly,thanks for your continuously help.
> I am not sure how to enter a local ISO path into the install URL field in
> the installation method "Network install(HTTP,FTP or NFS)" url to disk.
> I have tried to set up a http server in the s390x ,but find that the
> "localhost" is x86 which running virt-manager. Also , I try the
> "file:///var/lib/libvirt/images/**.iso", it don't find the iso image.
> So if you can provide*some examples of "local iso host"* ,it will be
> really better.
> Big Thanks~
> 
> Best Regards,
> Kevin
> On 2015年11月12日 04:05, Cole Robinson wrote:
>> On 11/11/2015 12:45 AM, Kevin Zhao wrote:
>>> Hi Cole & all,
>>>   There is a question just confusing me.
>>>   When I use virt-install , set the  --location parameter like this : 
>>> --location /tmp/**.iso, virt-install can search the iso and get the 
>>> tree.info
>>> , kernel.img and initrd.img. But when I replace the parameter "--location "
>>> with the "--cdrom", it will not be able to search the iso for kernel.img and
>>> initrd.img ,I need to specify the kernel and initrd(Maybe inn the arch 
>>> ppc64le
>>> and s390x).
>>>But when I use virt-manager, choose the cdrom I can not get the
>>> functions just like "--location". So does the virt-manager support the
>>> functions just like "--location" do? I see that by using network 
>>> installation
>>> , virt-manager will search for tree.info, how to use  it  to get a local iso
>>> treeinfo?
>>>My descriptions may not be very clear . So feel free to let me know 
>>> if
>>> you have any question.
>>>
>> The difference between --location $ISO and --cdrom $ISO are kinda subtle:
>>
>> --cdrom $ISO just passes the $ISO as a cdrom device to the guest
>>
>> --location $ISO tries to mount the $ISO locally, and treat that local path
>> like a --location $URL install, pulling out the kernel/initrd. This allows
>> passing in custom kernel args, but is kinda limited since you need root 
>> access
>> to mount the iso
>>
>> You can actually trigger this with virt-manager by entering a local ISO path
>> into the install URL field
>>
>> - Cole
>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Add the console target "sclp" for s390x

[Cole Robinson]

On 11/12/2015 08:48 PM, Kevin Zhao wrote:
> Add console target "sclp" for s390x ,since the newest Distro guests has
> supported the console target, solve some console issues in s390x.Also
> modified the test xml cover this change.
> ---
>  tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml | 2 ++
>  virtinst/guest.py  | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml 
> b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> index 3cccaca..7507641 100644
> --- a/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> +++ b/tests/cli-test-xml/compare/virt-install-s390x-cdrom-KVMIBM.xml
> @@ -31,6 +31,8 @@
>
>  
>  
> +  
> +
>  
>
>  
> diff --git a/virtinst/guest.py b/virtinst/guest.py
> index 959ab7e..88b2994 100644
> --- a/virtinst/guest.py
> +++ b/virtinst/guest.py
> @@ -628,6 +628,8 @@ class Guest(XMLBuilder):
>  
>  dev = VirtualConsoleDevice(self.conn)
>  dev.type = dev.TYPE_PTY
> +if self.os.is_s390x():
> +dev.target_type = "sclp"
>  self.add_device(dev)
>  
>  def add_default_video_device(self):
> 

Thanks, pushed now with regenerated test output since you missed a file

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Help: I want to know when virt-manager will update and release new version to Ubuntu and redhat or other Distro.

[Cole Robinson]

Yeah I'm slacking on getting the release out, per usual. I'll do my best to
get 1.3 out before Monday.

Thanks,
Cole

On 11/16/2015 12:41 AM, Kevin Zhao wrote:
> Hi Cole ,
> How is the releasing work going? My workmates in IBM want to use released
> virt-manager to build the packages. Now the newest version is 1.2.1 , so what
> is the next release dates? And what's the date that newest release version
> will cover the patches that have been committed ?
> Thanks for your kindly response :-)
> 
> On 2015年10月16日 09:26, Cole Robinson wrote:
>> On 10/14/2015 01:35 AM, Kevin Zhao wrote:
>>> Dear Everyone,
>>>  I am working on porting virt-manager to S390x ,now I have realized the
>>> function that using virt-manager on x86_64 to create and manage VM guests in
>>> S390x, also I have submit the patch to virt-manager mainline on 13th July,
>>> 2015.
>>>  But when I use "apt-get install virt-manager" to get the packages, I 
>>> see
>>> the version of virt-manager is 0.9.5. So I want to know that when 
>>> virt-manager
>>> will update or release new stable version to the Distro, such as Ubuntu
>>> ,redhat and so on. And if it has been released ,Pls tell me the support
>>> Distro.
>>>  If the released work has something to do , I am happy to take some work
>>> for pushing it to other Linux Distro community.
>>>  Thanks very much.Pls feel free to let me know if you have any 
>>> questions.
>>>
>> Yeah we are overdue for a release. I'll shoot for getting one out by the end
>> of the month, and it will end up in Fedora 23 which will be released by then.
>>
>> But whatever debian/ubuntu version you are using with 0.9.5... that version 
>> is
>> quite old, so you probably aren't on their latest distro release, maybe one 
>> of
>> the LTS versions. If you want latest and greatest packages you should update
>> to the latest version of your distro too
>>
>> - Cole
>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Question about the Gsettings and dconf and Design document.

[Cole Robinson]

On 11/16/2015 02:17 PM, Avaneendra Alugupalli wrote:
> hi
>  I am trying to understand the code for virt-manager and found that during the
> config object create, gets the connections / uris using the Gsettings API. and
> these are the entries in dconf database.
> 
> forchild inself._settings.list_children():
> childschema =self._root +"."+child
> self._settingsmap[child] =Gio.Settings.new(childschema)
> 
> 
> returns connections/uris as "qemu:///system" and "lxc:///". From the 
> 
> I can see that data
> /org.virt-manager.virt-manager.gschema.xml
> makes 
> default entry for these fields. How ever am unable to track who is updating 
> the connections/uris to "qemu:///system" and "lxc:///" strings.

The functions that add/remove/list the URIs in config.py are add_conn,
remove_conn, list_conn_uris respectively. They are called from engine.py

> Also is there any architecture/ design document to understand the code at very
> higher
> level?.

No unfortunately :/

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Curious Connectivity Issue

[Cole Robinson]

On 11/16/2015 06:28 AM, Gustave Stresen-Reuter wrote:
> Hi,
> 
> I'm new to the list and not even sure if this is the right list to be writing
> to so please feel free to redirect if needed.
> 
> I've summarized my issue in this blog post:
> http://chicagoitsystems.com/centos-7-kvm-macvtap-loses-all-connectivity/
> 
> However, since writing that, I've found that I can regain connectivity by
> stopping and restarting the guest that uses the Macvtap connections.
> Apparently, the command that executes that creates the interfaces does not
> include the "allow reconnections" options.+
> 
> I would really appreciate it if someone could point me in the direction I need
> to go to verify that this is indeed the issue (like, modifying the script used
> to start the machine from the command line to see if I can add… oh wait, maybe
> there is a switch in the XML that is not being set???)
> 
> Anyway, as you can see, I would appreciate any pointers people on this list
> can give.
> 

Are those screenshots from inside the guest, or is the host side screwed up?

If it's just the guest side, maybe this can be fixed by emulating a VM nic
unplug and replug event. You can do that with

sudo virsh domif-setlink $VM --interface $MAC --state up|down

So give that a shot and let us know if it works

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-install: looking for option to get rombar='off' in guest xml

[Cole Robinson]

On 11/17/2015 06:03 AM, P.A.M. van Dam (Pascal) wrote:
> Good morning all,
> 
> I've one small question. Due to the nature of my tests with UEFI/OVMF and 
> iSCSI booting I need to get the
> item  (e.g. disable network adapter rom) in my guests xml. 
> Editing it by hand is not really my preferred way. Which option(s) should
> I give virt-install to realise this for me?
> 

The virt-install/virt-xml option --hostdev rom_bar=on|off

You can set it for existing VMs host devices with virt-xml like:

  sudo virt-xml $VMNAME --edit all --hostdev rom_bar=off

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-install: looking for option to get rombar='off' in guest xml

[Cole Robinson]

On 11/17/2015 09:41 AM, Cole Robinson wrote:
> On 11/17/2015 06:03 AM, P.A.M. van Dam (Pascal) wrote:
>> Good morning all,
>>
>> I've one small question. Due to the nature of my tests with UEFI/OVMF and 
>> iSCSI booting I need to get the
>> item  (e.g. disable network adapter rom) in my guests xml. 
>> Editing it by hand is not really my preferred way. Which option(s) should
>> I give virt-install to realise this for me?
>>
> 
> The virt-install/virt-xml option --hostdev rom_bar=on|off
> 
> You can set it for existing VMs host devices with virt-xml like:
> 
>   sudo virt-xml $VMNAME --edit all --hostdev rom_bar=off
> 
> - Cole
> 

Also in the future you can see all sub options of a virt-install command line
option like:

  virt-install --hostdev help

- Cole


___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Question about the Gsettings and dconf and Design document.

[Cole Robinson]

On 11/17/2015 11:40 AM, Avaneendra Alugupalli wrote:
> hi Cole
>  Thanks for the response.
>>
> 
>>The functions that add/remove/list the URIs in config.py are add_conn,
>> remove_conn, list_conn_uris respectively. They are called from engine.py
> 
> From the code in virt-manager.py main handler, I find that the 
> config object is getting created before the engine object?. Is that for the 
> first
> time when I run the virt-manager app. config sees default values of 
> connections/
> uris to none [] and then engine creates them. And even if the app is exited
> we still have non default values ("qemu:///sysmtem" and "lxc://") in the 
> dconf?.
> perhaps not delete those values from dconf?.
> 

Sorry, I'm not really following what you are saying. Can you describe the
problem you are hitting, step by step, and exactly what you are trying to
determine?

Also, take a look at dconf-editor, it's a UI tool for exploring dconf values.
Might explain what you are seeing.

- Cole

> 
> On Mon, Nov 16, 2015 at 8:09 PM, Cole Robinson  <mailto:crobi...@redhat.com>> wrote:
> 
> On 11/16/2015 02:17 PM, Avaneendra Alugupalli wrote:
> > hi
> >  I am trying to understand the code for virt-manager and found that 
> during the
> > config object create, gets the connections / uris using the Gsettings 
> API. and
> > these are the entries in dconf database.
> >
> > forchild inself._settings.list_children():
> > childschema =self._root +"."+child
> > self._settingsmap[child] =Gio.Settings.new(childschema)
> >
> >
> > returns connections/uris as "qemu:///system" and "lxc:///". From the
> >
> > I can see that data
> >
> 
> <https://github.com/virt-manager/virt-manager/tree/master/data>/org.virt-manager.virt-manager.gschema.xml
> > makes
> > default entry for these fields. How ever am unable to track who is 
> updating
> > the connections/uris to "qemu:///system" and "lxc:///" strings.
> 
> The functions that add/remove/list the URIs in config.py are add_conn,
> remove_conn, list_conn_uris respectively. They are called from engine.py
> 
> > Also is there any architecture/ design document to understand the code 
> at very
> > higher
> > level?.
> 
> No unfortunately :/
> 
> - Cole
> 
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Question about the Gsettings and dconf and Design document.

[Cole Robinson]

On 11/17/2015 01:47 PM, Avaneendra Alugupalli wrote:
> Cole
>  Thanks for your time. Will try to ask again. Sorry for my bad english :).
> Will try my best
> this time.
> 
> I downloaded the code and tried to run the virt-manager.py of off eclipse
> Pydev IDE.
> Ran into some issues, not sure the order but ran 
> glib-compile-schemas data/*schamas*
> ran "python setup.py -install"
> 
> after that virt-manager sucessfully came up "with auto connected to lxc:///
> and qemu://system"
> *
> *
> Now I wanted to understand the code, ran the virt-manager in pdb -debugger. 
> stepping into the config code found that the
> "/org/virt-manager/virt-manager/connections/uris"
> is already populated with " lxc:/// and qemu://system" value.
> 
> but I see that this tuple in dconf DB is only updated by engine code. now
> wondering how 
> does config is able to see the " lxc:/// and qemu://system" values.
> 

If this was your first time running virt-manager, there is some first-run code
to try and determine a default connection, see engine.py:_add_default_conn as
a starting point.

That said, I don't know what could have caused the app to start up with both
qemu:///system _and_ lxc:/// in the connection list, it should only be one or
the other (or none, or an error message). You sure you definitely haven't run
virt-manager before?

FWIW you can test the first-run behavior again by using virt-manager --debug
--test-first-run, if you're just trying to figure out how it works

- Cole

> 
> On Tue, Nov 17, 2015 at 1:37 PM, Cole Robinson  <mailto:crobi...@redhat.com>> wrote:
> 
> On 11/17/2015 11:40 AM, Avaneendra Alugupalli wrote:
> > hi Cole
> >  Thanks for the response.
> >>
> >
> >>The functions that add/remove/list the URIs in config.py are add_conn,
> >> remove_conn, list_conn_uris respectively. They are called from 
> engine.py
> >
> > From the code in virt-manager.py main handler, I find that the
> > config object is getting created before the engine object?. Is that for 
> the first
> > time when I run the virt-manager app. config sees default values of 
> connections/
> > uris to none [] and then engine creates them. And even if the app is 
> exited
> > we still have non default values ("qemu:///sysmtem" and "lxc://") in 
> the dconf?.
> > perhaps not delete those values from dconf?.
> >
> 
> Sorry, I'm not really following what you are saying. Can you describe the
> problem you are hitting, step by step, and exactly what you are trying to
> determine?
> 
> Also, take a look at dconf-editor, it's a UI tool for exploring dconf 
> values.
> Might explain what you are seeing.
> 
> - Cole
> 
> >
> > On Mon, Nov 16, 2015 at 8:09 PM, Cole Robinson  <mailto:crobi...@redhat.com>
> > <mailto:crobi...@redhat.com <mailto:crobi...@redhat.com>>> wrote:
> >
> > On 11/16/2015 02:17 PM, Avaneendra Alugupalli wrote:
> > > hi
> > >  I am trying to understand the code for virt-manager and found
> that during the
> > > config object create, gets the connections / uris using the
> Gsettings API. and
> > > these are the entries in dconf database.
> > >
> > > forchild inself._settings.list_children():
> > > childschema =self._root +"."+child
> > > self._settingsmap[child] =Gio.Settings.new(childschema)
> > >
> > >
> > > returns connections/uris as "qemu:///system" and "lxc:///". From 
> the
> > >
> > > I can see that data
> > >
> >   
>  
> <https://github.com/virt-manager/virt-manager/tree/master/data>/org.virt-manager.virt-manager.gschema.xml
> > > makes
> > > default entry for these fields. How ever am unable to track who is
> updating
> > > the connections/uris to "qemu:///system" and "lxc:///" strings.
> >
> > The functions that add/remove/list the URIs in config.py are 
> add_conn,
> > remove_conn, list_conn_uris respectively. They are called from 
> engine.py
> >
> > > Also is there any architecture/ design document to understand the
> code at very
> > > higher
> > > level?.
> >
> > No unfortunately :/
> >
> > - Cole
> >
> >
> 
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Curious Connectivity Issue

[Cole Robinson]

On 11/17/2015 07:11 AM, Gustave Stresen-Reuter wrote:
> Here's the output of that command and to be clear, the guest loses
> connectivity on that interface. The host is still able to connect (but over
> the enp5s0 interface).
> 
> $ sudo virsh domif-setlink Smoothie --interface '52:54:00:3B:22:31' --state 
> down
> Device updated successfully
> 
> $ sudo virsh domif-setlink Smoothie --interface '52:54:00:3B:22:31' --state up
> Device updated successfully
> 
> Nevertheless, connectivity is not reestablished on the guest and the Network
> settings panel still does not show the ON/OFF button nor the Options button.
> 
> I shut down the guest. I would expect the interfaces to disappear from the
> host Network Settings control panel, but they don't (well, the Macvtap
> interfaces don't). So, just for kicks, with the guest shut down, I executed
> the 'up' command again. It replied "Device updated successfully" but again,
> the Network Settings control panel still doesn't show the on off button, nor
> an IPV6 address. In other words, unchanged.
> 
> I restarted the guest (Smoothie) and upon doing so, the macvtap0 interface
> came back up (the Network Settings control panel in the host shows the ON/OFF
> button and the Options button is also visible). And as one would expect,
> connectivity is restored.
> 
> So, I did it all again, but this time, I didn't execute the 'up' command.
> Rather, I just shut the guest down and started it up again. This time, the
> Network Settings control panel on the host crashed (disappeared) when I
> unplugged the ethernet cable. Other than that, everything was the same
> (connectivity was restored).
> 
> My question is, is this a CentOS 7 issue or a virt issue? I'm beginning to
> suspect the former.
> 

I'm guessing it's centos related as well, maybe NetworkManager. On Fedora 23 I
just tried starting a VM with macvtap, disconnecting my network, reconnecting,
and the VM resumed connectivity. Also in the gnome-shell network panel, it
doesn't show me any macvtap interfaces like you are seeing.

Might be worth looking into disabling NetworkManager and trying the manual
'network' service, see if that helps.

> And before I go, where can I find a complete list of virsh commands (so I
> don't have to bother others for the info)?
> 

'virsh help' will list them.

- Cole

> 
> On Tue, Nov 17, 2015 at 11:25 AM Gustave Stresen-Reuter
> mailto:tedmaster...@gmail.com>> wrote:
> 
> Hi again. Sorry for the last email. $VM should obviously be the name of
> the guest (Smoothie in this case) and the $MAC should be the MAC address
> of the interface in question. Duh.
> 
> I'll let you know how it goes.
> 
> Ted
> 
> On Tue, Nov 17, 2015 at 11:06 AM Gustave Stresen-Reuter
> mailto:tedmaster...@gmail.com>> wrote:
> 
> Hi and thanks for checking this out. If I can't get this resolved soon
> I'm going to have to install an older version of the host OS, get
> everything configured, and then try upgrading. Is CentOS a good choice
> for the host? I'd use REL but I've never been clear on the licensing
> and don't want to put myself in a spot unnecessarily.
> 
> Those screen shots are from the host, unfortunately. Apparently, when
> the Smoothwall starts up, it executes some sort of script that creates
> the Macvtap interfaces and that seems to be where the issue is. If I
> unplug the cable without those interfaces created, and plug it back
> in, connectivity is restored without issue.
> 
> I'll try the command you suggest but…
> 
> What should the value of $VM be? macvtap0 or enp5s0 (the interface
> defined by the host)? Same question for $MAC…
> 
> Thanks again for lending a hand. This is frustrating because these
> sorts of things normally just work (thankfully).
> 
> Kind regards,
> 
> Ted Stresen-Reuter
> 
> On Tue, Nov 17, 2015 at 1:13 AM Cole Robinson  <mailto:crobi...@redhat.com>> wrote:
> 
> On 11/16/2015 06:28 AM, Gustave Stresen-Reuter wrote:
> > Hi,
> >
> > I'm new to the list and not even sure if this is the right list
> to be writing
> > to so please feel free to redirect if needed.
> >
> > I've summarized my issue in this blog post:
> >
> 
> http://chicagoitsystems.com/centos-7-kvm-macvtap-loses-all-connectivity/
>   

Re: [virt-tools-list] How does the memory usage calculated?

[Cole Robinson]

On 11/18/2015 09:44 AM, Richard W.M. Jones wrote:
> On Wed, Nov 18, 2015 at 01:04:32PM +, 张强 wrote:
>> Hi all,
>> I’m studying the source code, and I saw this in domain.py around line 164:
>> …
>> curmem = stats['rss']
>> totalmem = stats['actual']
>> except libvirt.libvirtError, err:
>> logging.error("Error reading mem stats: %s", err)
>>
>> pcentCurrMem = curmem * 100.0 / totalmem
>> pcentCurrMem = max(0.0, min(pcentCurrMem, 100.0))
>> …
>>
>> But using this algorithm, I’m always getting results that are greater than 
>> 100:
> dom.memoryStats()
>> {'actual': 16777216L, 'rss': 17062900L}
>>
>> 17062900 * 100 / 16777216 = 101.7028…
>>
>> Is this normal?
> 
> The VIR_DOMAIN_MEMORY_STAT_RSS statistic returned for qemu/KVM guests
> is the resident set size (RSS) of the qemu process.  Of course that
> includes all the overhead of qemu, such as host-side structures used
> when emulating devices.  Plus the guest RAM, which is just a regular
> malloc-style allocation inside qemu and so also contributes to the RSS.
> 
> The 'actual' field seems to come from the libvirt
> VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON statistic which is found by
> sending the query-balloon monitor command to the guest.  The returned
> value is the guest's get_current_ram_size() (or less if the balloon is
> "inflated", but for the majority of guests the balloon is never used).
> 
> Given all that, it seems reasonable that rss > actual, and so you'd
> get a number > 100%.  Sometimes.  It also seems to me that if the
> guest RAM had been allocated but not accessed, you might see rss < actual.
> 
> rss / actual seems like a fairly meaningless number from a
> virt-manager point of view.
> 

Yeah I think this calculation is leftover from when virt-manager's memory
reporting just tracked memory ballooning, so pcentCurrMem was 
/ . I'll look into cleaning it up

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Help: I want to know when virt-manager will update and release new version to Ubuntu and redhat or other Distro.

[Cole Robinson]

Yes it will cover everything up until the moment I do the release.

- Cole

On 11/18/2015 02:03 AM, Kevin Zhao wrote:
> Hi Cole ,
> Another question :-)
> Release version 1.3 cover the patch before the date ?   Will it cover
> the patch before 11.18(My latest patch ) ?
> Thanks very much
> 
> Best Regards,
> Kevin
> 
> On 2015年11月17日 08:58, Cole Robinson wrote:
>> Yeah I'm slacking on getting the release out, per usual. I'll do my best to
>> get 1.3 out before Monday.
>>
>> Thanks,
>> Cole
>>
>> On 11/16/2015 12:41 AM, Kevin Zhao wrote:
>>> Hi Cole ,
>>> How is the releasing work going? My workmates in IBM want to use released
>>> virt-manager to build the packages. Now the newest version is 1.2.1 , so 
>>> what
>>> is the next release dates? And what's the date that newest release version
>>> will cover the patches that have been committed ?
>>> Thanks for your kindly response :-)
>>>
>>> On 2015年10月16日 09:26, Cole Robinson wrote:
>>>> On 10/14/2015 01:35 AM, Kevin Zhao wrote:
>>>>> Dear Everyone,
>>>>>   I am working on porting virt-manager to S390x ,now I have realized 
>>>>> the
>>>>> function that using virt-manager on x86_64 to create and manage VM guests 
>>>>> in
>>>>> S390x, also I have submit the patch to virt-manager mainline on 13th July,
>>>>> 2015.
>>>>>   But when I use "apt-get install virt-manager" to get the packages,
>>>>> I see
>>>>> the version of virt-manager is 0.9.5. So I want to know that when
>>>>> virt-manager
>>>>> will update or release new stable version to the Distro, such as Ubuntu
>>>>> ,redhat and so on. And if it has been released ,Pls tell me the support
>>>>> Distro.
>>>>>   If the released work has something to do , I am happy to take some
>>>>> work
>>>>> for pushing it to other Linux Distro community.
>>>>>   Thanks very much.Pls feel free to let me know if you have any
>>>>> questions.
>>>>>
>>>> Yeah we are overdue for a release. I'll shoot for getting one out by the 
>>>> end
>>>> of the month, and it will end up in Fedora 23 which will be released by 
>>>> then.
>>>>
>>>> But whatever debian/ubuntu version you are using with 0.9.5... that
>>>> version is
>>>> quite old, so you probably aren't on their latest distro release, maybe
>>>> one of
>>>> the LTS versions. If you want latest and greatest packages you should 
>>>> update
>>>> to the latest version of your distro too
>>>>
>>>> - Cole
>>>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] How does the memory usage calculated?

[Cole Robinson]

On 11/18/2015 09:54 AM, Cole Robinson wrote:
> On 11/18/2015 09:44 AM, Richard W.M. Jones wrote:
>> On Wed, Nov 18, 2015 at 01:04:32PM +, 张强 wrote:
>>> Hi all,
>>> I’m studying the source code, and I saw this in domain.py around line 164:
>>> …
>>> curmem = stats['rss']
>>> totalmem = stats['actual']
>>> except libvirt.libvirtError, err:
>>> logging.error("Error reading mem stats: %s", err)
>>>
>>> pcentCurrMem = curmem * 100.0 / totalmem
>>> pcentCurrMem = max(0.0, min(pcentCurrMem, 100.0))
>>> …
>>>
>>> But using this algorithm, I’m always getting results that are greater than 
>>> 100:
>>>>>> dom.memoryStats()
>>> {'actual': 16777216L, 'rss': 17062900L}
>>>
>>> 17062900 * 100 / 16777216 = 101.7028…
>>>
>>> Is this normal?
>>
>> The VIR_DOMAIN_MEMORY_STAT_RSS statistic returned for qemu/KVM guests
>> is the resident set size (RSS) of the qemu process.  Of course that
>> includes all the overhead of qemu, such as host-side structures used
>> when emulating devices.  Plus the guest RAM, which is just a regular
>> malloc-style allocation inside qemu and so also contributes to the RSS.
>>
>> The 'actual' field seems to come from the libvirt
>> VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON statistic which is found by
>> sending the query-balloon monitor command to the guest.  The returned
>> value is the guest's get_current_ram_size() (or less if the balloon is
>> "inflated", but for the majority of guests the balloon is never used).
>>
>> Given all that, it seems reasonable that rss > actual, and so you'd
>> get a number > 100%.  Sometimes.  It also seems to me that if the
>> guest RAM had been allocated but not accessed, you might see rss < actual.
>>
>> rss / actual seems like a fairly meaningless number from a
>> virt-manager point of view.
>>
> 
> Yeah I think this calculation is leftover from when virt-manager's memory
> reporting just tracked memory ballooning, so pcentCurrMem was 
> / . I'll look into cleaning it up
> 

We still need to do the 'rss / actual' allocation to get meaningful memory
stats from the lxc driver, but I pushed a commit to virt-manager.git now that
uses qemu's proper guest coordinated memory stats. In order to get these, we
need to call DomainSetMemoryStatsInterval so qemu actually does the polling for 
us

commit e68efe810375826a0e72864f4e60b3ee3e0d9bb8
Author: Cole Robinson 
Date:   Wed Nov 18 21:17:22 2015 -0500

domain: Use setMemoryStatsPeriod for QEMU

Since that's what is required to get cooperative memory stats from
the guest balloon driver.


- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] How does the memory usage calculated?

[Cole Robinson]

On 11/18/2015 10:29 PM, 张强 wrote:
> Hi Cole, Richard,
> 
> Thanks for your answers.
> 
> Cole, I looked at your commit, I think we should increase required 
> libvirt-python version to use 
> SetMemoryStatsPeriod. 
> 
> This function seems fairly new, my libvirt is 0.10.x, and still it doesn't 
> support this function, let 
> alone the 0.4.0 we listed in pre-requisite in the INSTALL file... I think 
> adding install_requires to 
> setup.py is a good idea.
> 

Notice the added check to support.py in that commit. We won't use the API if
the unless the following bits support it: libvirt daemon version,
libvirt-python, hypervisor.

I'm guessing we don't work well anymore with libvirt-python-0.4.0 but we
definitely will work fine with libvirt less than 1.1.1 where this API was
introduced

- Cole

> 
> -邮件原件-
> 发件人: Cole Robinson [mailto:crobi...@redhat.com] 
> 发送时间: 2015年11月19日 10:26
> 收件人: Richard W.M. Jones; 张强
> 抄送: virt-tools-list@redhat.com
> 主题: Re: [virt-tools-list] How does the memory usage calculated?
> 
> On 11/18/2015 09:54 AM, Cole Robinson wrote:
>> On 11/18/2015 09:44 AM, Richard W.M. Jones wrote:
>>> On Wed, Nov 18, 2015 at 01:04:32PM +, 张强 wrote:
>>>> Hi all,
>>>> I’m studying the source code, and I saw this in domain.py around line 164:
>>>> …
>>>> curmem = stats['rss']
>>>> totalmem = stats['actual']
>>>> except libvirt.libvirtError, err:
>>>> logging.error("Error reading mem stats: %s", err)
>>>>
>>>> pcentCurrMem = curmem * 100.0 / totalmem pcentCurrMem = max(0.0, 
>>>> min(pcentCurrMem, 100.0)) …
>>>>
>>>> But using this algorithm, I’m always getting results that are greater than 
>>>> 100:
>>>>>>> dom.memoryStats()
>>>> {'actual': 16777216L, 'rss': 17062900L}
>>>>
>>>> 17062900 * 100 / 16777216 = 101.7028…
>>>>
>>>> Is this normal?
>>>
>>> The VIR_DOMAIN_MEMORY_STAT_RSS statistic returned for qemu/KVM guests 
>>> is the resident set size (RSS) of the qemu process.  Of course that 
>>> includes all the overhead of qemu, such as host-side structures used 
>>> when emulating devices.  Plus the guest RAM, which is just a regular 
>>> malloc-style allocation inside qemu and so also contributes to the RSS.
>>>
>>> The 'actual' field seems to come from the libvirt 
>>> VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON statistic which is found by 
>>> sending the query-balloon monitor command to the guest.  The returned 
>>> value is the guest's get_current_ram_size() (or less if the balloon 
>>> is "inflated", but for the majority of guests the balloon is never used).
>>>
>>> Given all that, it seems reasonable that rss > actual, and so you'd 
>>> get a number > 100%.  Sometimes.  It also seems to me that if the 
>>> guest RAM had been allocated but not accessed, you might see rss < actual.
>>>
>>> rss / actual seems like a fairly meaningless number from a 
>>> virt-manager point of view.
>>>
>>
>> Yeah I think this calculation is leftover from when virt-manager's 
>> memory reporting just tracked memory ballooning, so pcentCurrMem was 
>>  / . I'll look into cleaning it up
>>
> 
> We still need to do the 'rss / actual' allocation to get meaningful memory 
> stats from the lxc driver, but I pushed a commit to virt-manager.git now that 
> uses qemu's proper guest coordinated memory stats. In order to get these, we 
> need to call DomainSetMemoryStatsInterval so qemu actually does the polling 
> for us
> 
> commit e68efe810375826a0e72864f4e60b3ee3e0d9bb8
> Author: Cole Robinson 
> Date:   Wed Nov 18 21:17:22 2015 -0500
> 
> domain: Use setMemoryStatsPeriod for QEMU
> 
> Since that's what is required to get cooperative memory stats from
> the guest balloon driver.
> 
> 
> - Cole
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] storage: remove attempt counter from disk allocation thread

[Cole Robinson]

On 11/19/2015 09:11 AM, Pavel Hrdina wrote:
> Remove the lookup counter from _progress_thread, it's not necessary, the
> loop is terminated by _install_finished boolean.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1270277
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  virtinst/storage.py | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/virtinst/storage.py b/virtinst/storage.py
> index e50b78f..9901cfb 100644
> --- a/virtinst/storage.py
> +++ b/virtinst/storage.py
> @@ -809,25 +809,20 @@ class StorageVolume(_StorageObject):
> "'%s': '%s'" % (self.name, str(e)))
>  
>  def _progress_thread(self, meter):
> -lookup_attempts = 10
>  vol = None
>  if not meter:
>  return
>  
> -while lookup_attempts > 0:
> +while True:
>  try:
>  if not vol:
>  vol = self.pool.storageVolLookupByName(self.name)
>  vol.info()
>  break
>  except:
> -lookup_attempts -= 1
>  time.sleep(.2)
>  if self._install_finished:
>  break
> -else:
> -continue
> -break
>  
>  if vol is None:
>  logging.debug("Couldn't lookup storage volume in prog thread.")
> 

ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] man: virt-install: Documenting bood_order parameter

[Cole Robinson]

On 11/23/2015 04:40 AM, Kothapally Madhu Pavan wrote:
> virt-install man page doesn't have boot_order documentation.
> This patch documents boot_order.
> 
> Signed-off-by: Kothapally Madhu Pavan 
> ---
>  man/virt-install.pod |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/man/virt-install.pod b/man/virt-install.pod
> index 4dce2df..1f3f535 100644
> --- a/man/virt-install.pod
> +++ b/man/virt-install.pod
> @@ -575,6 +575,10 @@ Disk device type. Value can be 'cdrom', 'disk', 'lun' or 
> 'floppy'. Default is
>  'disk'. If a 'cdrom' is specified, and no install method is chosen, the
>  cdrom is used as the install media.
>  
> +=item B
> +
> +Guest installation with multiple disks will need this parameter to boot 
> correctly after being installed. A boot_order parameter will take values 
> 1,2,3,... Devices with lower value has higher priority.
> +
>  =item B
>  
>  Disk bus type. Value can be 'ide', 'sata', 'scsi', 'usb', 'virtio' or 'xen'.

Thanks, fixed the typo in the subject and pushed

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [ Required ] Release New version

[Cole Robinson]

On 11/24/2015 04:26 AM, Leno Hou wrote:
> Hi guys,
> 
> How about release new version ?  1.2.2 or 1.3 ? 
> As we might know, there are lots of the new features and
> architectures. i.e. s390x  has been merged to master
>Actually, we're waiting new version that included Kevin Zhao's patches
> support s390x. 
>Thanks！
> 

I assume this is about virt-manager... yes I'm trying to fix two remaining
bugs, and finish testing. But it's my main priority now, hopefully done by the
end of the day.

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] ANNOUNCE: virt-manager 1.3.0 released

[Cole Robinson]

I'm happy to announce the release of virt-manager 1.3.0!

virt-manager is a desktop application for managing KVM, Xen, and LXC
virtualization via libvirt.

The release can be downloaded from:

http://virt-manager.org/download/

This release includes:

- Git hosting moved to http://github.com/virt-manager/virt-manager
- Switch translation infrastructure from transifex to fedora.zanata.org
- Add dogtail UI tests and infrastructure
- Improved support for s390x kvm (Kevin Zhao)
- virt-install and virt-manager now remove created disk images if VM
  install startup fails
- Replace urlgrabber usage with requests and urllib2
- virt-install: add --network virtualport support for openvswitch
  (Daniel P. Berrange)
- virt-install: support multiple --security labels
- virt-install: support --features kvm_hidden=on|off (Pavel Hrdina)
- virt-install: add --features pmu=on|off
- virt-install: add --features pvspinlock=on|off (Abhijeet Kasurde)
- virt-install: add --events on_lockfailure=on|off (Abhijeet Kasurde)
- virt-install: add --network link_state=up|down
- virt-install: add --vcpu placement=static|auto

Thanks to everyone who has contributed to this release through testing,
bug reporting, submitting patches, and otherwise sending in feedback!

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [Help] virt-manager loading failed after 1.3

[Cole Robinson]

On 12/02/2015 08:58 AM, Kevin Zhao wrote:
> Hi Cole && All,
> I want to install a virt-manager in Local S390x, the Distro in S390x
> is RHEL 7.1,this distro of S390x doesn't support virt-manager. I installed 
> related dependencies and run command virt-manager --debug.
> It show below:
> 
> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (virt-manager:203) GTK
> version: 3.8.8
> [三, 02 12月 2015 14:53:15 virt-manager 24293] ERROR (importer:51) Could not
> find any typelib for AppIndicator3
> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (engine:474) libguestfs
> inspection support: False
> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (systray:154) Showing
> systray: False
> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (engine:236) About to
> connect to uris ['qemu:///system']
> [三, 02 12月 2015 14:53:18 virt-manager 24293] DEBUG (virt-manager:54) Error
> starting virt-manager: new_sync() takes exactly 7 arguments (6 given)
> Traceback (most recent call last):
>   File "./virt-manager", line 264, in 
> main()
>   File "./virt-manager", line 256, in main
> api = StartupAPI()
>   File "/root/virt-manager/virtManager/dbusapi.py", line 105, in __init__
> self._proxy = self._init_dbus()
>   File "/root/virt-manager/virtManager/dbusapi.py", line 118, in _init_dbus
> "org.freedesktop.DBus")
>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 137, in 
> constructor
> return info.invoke(cls, *args, **kwargs)
> TypeError: new_sync() takes exactly 7 arguments (6 given)
> Traceback (most recent call last):
>   File "./virt-manager", line 264, in 
> main()
>   File "./virt-manager", line 256, in main
> api = StartupAPI()
>   File "/root/virt-manager/virtManager/dbusapi.py", line 105, in __init__
> self._proxy = self._init_dbus()
>   File "/root/virt-manager/virtManager/dbusapi.py", line 118, in _init_dbus
> "org.freedesktop.DBus")
>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 137, in 
> constructor
> return info.invoke(cls, *args, **kwargs)
> TypeError: new_sync() takes exactly 7 arguments (6 given)
> 
>   **I think it may be resulted from the patch : *
> ** **a9bc56add35e94854b0209144c1d83d524e1ddb4**
> ** virt-manager: revive cli dbus API (bz 1162815)*
>Because I checkout to the Head before this , it will work fine.Also maybe
> my virt-manager parameters is not correct. So I am here for your help about
> this :-)
>Sincerely thanks for your response :-)
> 

Yeah there's issues on non-latest pygobject3:

https://bugzilla.redhat.com/show_bug.cgi?id=1162815

I'll have a new release out by next week

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Encryption during migration

[Cole Robinson]

On 12/03/2015 12:50 AM, Renju M wrote:
> Hello,
> 
> I had been using virt-manager to create and manage virtual machines for my
> project. Does virt-manager encrypts data before/during migration of virtual
> machines from one host to another?
> 

By default, no. But if you use libvirt's tunnelled migration option then it's
likely encrypted; data is sent over the libvirt connection which is usually
tunnelled over ssh

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [Help] virt-manager loading failed after 1.3

[Cole Robinson]

On 12/02/2015 09:00 AM, Cole Robinson wrote:
> On 12/02/2015 08:58 AM, Kevin Zhao wrote:
>> Hi Cole && All,
>> I want to install a virt-manager in Local S390x, the Distro in S390x
>> is RHEL 7.1,this distro of S390x doesn't support virt-manager. I installed 
>> related dependencies and run command virt-manager --debug.
>> It show below:
>>
>> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (virt-manager:203) GTK
>> version: 3.8.8
>> [三, 02 12月 2015 14:53:15 virt-manager 24293] ERROR (importer:51) Could not
>> find any typelib for AppIndicator3
>> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (engine:474) libguestfs
>> inspection support: False
>> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (systray:154) Showing
>> systray: False
>> [三, 02 12月 2015 14:53:15 virt-manager 24293] DEBUG (engine:236) About to
>> connect to uris ['qemu:///system']
>> [三, 02 12月 2015 14:53:18 virt-manager 24293] DEBUG (virt-manager:54) Error
>> starting virt-manager: new_sync() takes exactly 7 arguments (6 given)
>> Traceback (most recent call last):
>>   File "./virt-manager", line 264, in 
>> main()
>>   File "./virt-manager", line 256, in main
>> api = StartupAPI()
>>   File "/root/virt-manager/virtManager/dbusapi.py", line 105, in __init__
>> self._proxy = self._init_dbus()
>>   File "/root/virt-manager/virtManager/dbusapi.py", line 118, in _init_dbus
>> "org.freedesktop.DBus")
>>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 137, in 
>> constructor
>> return info.invoke(cls, *args, **kwargs)
>> TypeError: new_sync() takes exactly 7 arguments (6 given)
>> Traceback (most recent call last):
>>   File "./virt-manager", line 264, in 
>> main()
>>   File "./virt-manager", line 256, in main
>> api = StartupAPI()
>>   File "/root/virt-manager/virtManager/dbusapi.py", line 105, in __init__
>> self._proxy = self._init_dbus()
>>   File "/root/virt-manager/virtManager/dbusapi.py", line 118, in _init_dbus
>> "org.freedesktop.DBus")
>>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 137, in 
>> constructor
>> return info.invoke(cls, *args, **kwargs)
>> TypeError: new_sync() takes exactly 7 arguments (6 given)
>>
>>   **I think it may be resulted from the patch : *
>> ** **a9bc56add35e94854b0209144c1d83d524e1ddb4**
>> ** virt-manager: revive cli dbus API (bz 1162815)*
>>Because I checkout to the Head before this , it will work fine.Also maybe
>> my virt-manager parameters is not correct. So I am here for your help about
>> this :-)
>>Sincerely thanks for your response :-)
>>
> 
> Yeah there's issues on non-latest pygobject3:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1162815
> 
> I'll have a new release out by next week
> 

I've cut version 1.3.1 now which should fix these issues

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Added fix for deleting disk when removing disk from a VM

[Cole Robinson]

On 12/03/2015 07:26 AM, Abhijeet Kasurde wrote:
> This fix adds a user dialog box for confirmation specific to disk,
> also deletes disk from storage.
> 
> Signed-off-by: Abhijeet Kasurde 
> ---

Thanks for the patch! For reference there's a bug for this:
https://bugzilla.redhat.com/show_bug.cgi?id=1058051

Unfortunately this isn't sufficient. The main problem is it ties together
'delete the media' with 'remove the device from the VM'. There needs to be an
option to just remove the device and leave the media intact.

I think we should find a way to share bits of delete.py for this purpose. It
already handles storage deletion, and takes into account bits like if the disk
is readonly, shareable, or in use by other VMs. We would need to use a
different dialog but the guts would be shared.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Added fix for deleting disk when removing disk from a VM

[Cole Robinson]

On 12/07/2015 11:55 PM, Abhijeet Kasurde wrote:
> Hi Cole,
> 
> On 12/07/2015 11:30 PM, Cole Robinson wrote:
>> On 12/03/2015 07:26 AM, Abhijeet Kasurde wrote:
>>> This fix adds a user dialog box for confirmation specific to disk,
>>> also deletes disk from storage.
>>>
>>> Signed-off-by: Abhijeet Kasurde 
>>> ---
>> Thanks for the patch! For reference there's a bug for this:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1058051
> OK.
>> Unfortunately this isn't sufficient. The main problem is it ties together
>> 'delete the media' with 'remove the device from the VM'. There needs to be an
>> option to just remove the device and leave the media intact.
> Can you / anyone suggest workflow or flow diagram for same?

The simplest is just a dialog that asks 'Are you sure you want to remove the
device for %(path)s?' with a checkbox "Delete associated storage file". The
checkbox will always be unchecked by default. If the disk image is in use by
other VMs we should probably show an extra little warning message, or show a
warning icon with a tooltip, like we do in the delete dialog.

In this case it doesn't really fit with the 'Dont ask me again' model, so I
suggest ignoring any settings for that.

I don't do flow diagrams :) but if you take a rough cut at it I can play with
it and give feedback/patches

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH v1 1/2] Modify the default graphics device to "vnc" for ppc64 and ppc64le

[Cole Robinson]

On 12/15/2015 08:06 AM, Kevin Zhao wrote:
> Modify the default graphics device to "vnc",since the powerpc
> does't support spice devices.Otherwise, virt-manager can not
> be used in ppc64 and ppc64le hardware.So that change  make
> virt-manager supports arch "ppc64" and "ppc64le".Also add
> a test case to cover this change.
> ---
>  .../compare/virt-install-ppc64le-cdrom-f22.xml | 39 
> ++
>  tests/clitest.py   |  2 +-
>  virtinst/guest.py  |  3 ++
>  3 files changed, 43 insertions(+), 1 deletion(-)
>  create mode 100644 
> tests/cli-test-xml/compare/virt-install-ppc64le-cdrom-f22.xml
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-ppc64le-cdrom-f22.xml 
> b/tests/cli-test-xml/compare/virt-install-ppc64le-cdrom-f22.xml
> new file mode 100644
> index 000..c710169
> --- /dev/null
> +++ b/tests/cli-test-xml/compare/virt-install-ppc64le-cdrom-f22.xml
> @@ -0,0 +1,39 @@
> +
> +  foobar
> +  ----
> +  1048576
> +  1048576
> +  1
> +  
> +hvm
> +
> +
> +  
> +  
> +  destroy
> +  destroy
> +  destroy
> +  
> +/usr/bin/qemu-system-ppc64
> +
> +  
> +  
> +  
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +  
> +  
> +
> +
> +
> +
> +  
> +
> +  
> +
> diff --git a/tests/clitest.py b/tests/clitest.py
> index 994b415..f2085cc 100644
> --- a/tests/clitest.py
> +++ b/tests/clitest.py
> @@ -702,7 +702,7 @@ c.add_compare("--connect %(URI-KVM-AARCH64)s --disk 
> %(EXISTIMG1)s --import --os-
>  c.add_compare("--arch ppc64 --machine pseries --boot network --disk 
> %(EXISTIMG1)s --os-variant fedora20 --network none", "ppc64-pseries-f20")
>  c.add_compare("--arch ppc64 --boot network --disk %(EXISTIMG1)s --os-variant 
> fedora20 --network none", "ppc64-machdefault-f20")
>  c.add_compare("--connect %(URI-KVM-PPC64LE)s --import --disk %(EXISTIMG1)s 
> --os-variant fedora20", "ppc64le-kvm-import")
> -
> +c.add_compare("--arch ppc64 --machine pseries --connect %(URI-KVM-PPC64LE)s 
> --disk %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant 
> fedora22", "ppc64le-cdrom-f22")
>  # s390x tests
>  c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21", 
> "s390x-cdrom")
>  c.add_compare("--arch s390x --machine s390-ccw-virtio --connect 
> %(URI-KVM-S390X-KVMIBM)s --boot kernel=/kernel.img,initrd=/initrd.img --disk 
> %(EXISTIMG1)s --disk %(EXISTIMG3)s,device=cdrom --os-variant fedora21 
> --watchdog diag288,action=reset", "s390x-cdrom-KVMIBM")
> diff --git a/virtinst/guest.py b/virtinst/guest.py
> index 6284b1f..f075345 100644
> --- a/virtinst/guest.py
> +++ b/virtinst/guest.py
> @@ -1125,6 +1125,9 @@ class Guest(XMLBuilder):
>"Using vnc.")
>  gtype = "vnc"
>  
> +    if self.os.is_ppc64():
> +gtype = "vnc"
> +
>  gfx.type = gtype
>  
>  for dev in self.get_devices("graphics"):
> 

Thanks for the report, indeed our behavior is wrong. But this fix isn't
correct... spice is only supported for qemu running on x86 _host_, it doesn't
have anything to do with the qemu emulated arch. I pushed a patch with the
proper fix:

commit 33ca0fff7dab62bfa64a24bcdd1d862a9c17245f
Author: Cole Robinson 
Date:   Tue Dec 15 21:06:19 2015 +0800

Only use spice on x86

qemu isn't compiled with spice support for non-x86

Reported-by: Kevin Zhao 


- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] Prohibit adding PCI host devices to container

[Cole Robinson]

On 12/23/2015 07:01 AM, Pavel Fedin wrote:
> libvirt does not allow this and attempt to do so causes error during domain
> startup. Prevent this in the beginning instead with correct explanation.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  virtManager/addhardware.py | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/virtManager/addhardware.py b/virtManager/addhardware.py
> index 8de710d..6d812e3 100644
> --- a/virtManager/addhardware.py
> +++ b/virtManager/addhardware.py
> @@ -376,9 +376,14 @@ class vmmAddHardware(vmmGObjectUI):
>self.conn.is_nodedev_capable(),
>_("Connection does not support host device 
> enumeration"),
>"usb")
> +if self.vm.is_container():
> +enabled = False
> +errstr = _("Not supported for this guest type")
> +else:
> +enabled = self.conn.is_nodedev_capable()
> +errstr = _("Connection does not support host device enumeration")
>  add_hw_option("PCI Host Device", "system-run", PAGE_HOSTDEV,
> -  self.conn.is_nodedev_capable(),
> -  _("Connection does not support host device 
> enumeration"),
> +  enabled, errstr,
>"pci")
>  add_hw_option("Video", "video-display", PAGE_VIDEO, True,
>_("Libvirt version does not support video devices."))
> 

Thanks, pushed with some minor tweaks

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Providing SMBIOS information to the guest

[Cole Robinson]

On 01/06/2016 01:40 PM, Charles Arnold wrote:
> libvirt allows specifying detailed SMBIOS info
> 
> http://libvirt.org/formatdomain.html#elementsSysinfo
> 
> Would there be interest in accepting a feature enhancment
> where virt-install options allow passing SMBIOS information
> to the guest. This would allow tools such as dmidecode to
> report meaningful information in the guest.
> 

Yes, an option for virt-install would be nice. Ideally virt-install/virt-xml
would allow configuring every domain XML option

> Additionally, some graphical elements could be added to
> virt-manager giving a user friendly interface to SMBIOS
> fields.
> 

Maybe. Can you describe the usecase? How many fields are we talking about?

I think it only makes sense to add to virt-manager if it's really essential
information for some particular usecase. Probably only if it's required at
install time, otherwise we can just point people at using virt-xml on the
command line which is easier to document.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] connection: fix detection that libvirtd is stopped

[Cole Robinson]

On 01/06/2016 04:47 AM, Pavel Hrdina wrote:
> In case that libvirtd is stopped, we could receive another type of error
> from libvirt "libvirtError: internal error: client socket is closed".
> This one is usually reported from local connection.
> 
> Resloves: https://bugzilla.redhat.com/show_bug.cgi?id=1273289
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  virtManager/connection.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/virtManager/connection.py b/virtManager/connection.py
> index b8694af..bd604b9 100644
> --- a/virtManager/connection.py
> +++ b/virtManager/connection.py
> @@ -1298,6 +1298,7 @@ class vmmConnection(vmmGObject):
>  from_remote = getattr(libvirt, "VIR_FROM_REMOTE", None)
>  from_rpc = getattr(libvirt, "VIR_FROM_RPC", None)
>  sys_error = getattr(libvirt, "VIR_ERR_SYSTEM_ERROR", None)
> +internal_error = getattr(libvirt, "VIR_ERR_INTERNAL_ERROR", None)
>  
>  dom = -1
>  code = -1
> @@ -1309,7 +1310,7 @@ class vmmConnection(vmmGObject):
>  self.get_uri(), exc_info=True)
>  
>  if (dom in [from_remote, from_rpc] and
> -code in [sys_error]):
> +code in [sys_error, internal_error]):
>  e = None
>  logging.debug("Not showing user error since libvirtd "
>  "appears to have stopped.")
> 

ACK

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-install copies part of a pool's definition into a domain's disk definition - should it copy more or less?

[Cole Robinson]

It's likely not trivial, but if you're motivated take a look at this bug fix:

commit e44b95149bdfe83d49b1b6026969fc7304eb1761
Author: Anatoly Belikov 
Date:   Tue Jan 27 16:10:12 2015 +0300

devicedisk: fix source name attribute for gluster volumes


It shows test suite additions, and one of the source files involved.

- Cole

On 01/07/2016 01:01 PM, Peter Crowther wrote:
> Thanks, Cole. Could you give me a rough idea of where to look? I can then try
> to produce a patch for you to laugh at ;-).
> 
> Cheers,
> 
> Peter
> 
> On 7 Jan 2016 16:10, "Cole Robinson"  <mailto:crobi...@redhat.com>> wrote:
> 
> On 01/07/2016 07:04 AM, Peter Crowther wrote:
> > I'm trying to use virt-install to create a domain where the disks are 
> on a
> > Ceph storage pool.  I've created a libvirt pool as follows:
> >
> > ID=kvm
> > POOL=vmlive
> > SECRET_UUID=036f507c-d66c-4fa6-a624-6764e6c77996
> >
> > POOL_DEFINITION_FILE=~/pool-$POOL.xml
> > cat > $POOL_DEFINITION_FILE << EOF
> > 
> >   $POOL
> >   
> > $POOL
> > 
> > 
> > 
> >   
> > 
> >   
> > 
> > EOF
> > virsh pool-define $POOL_DEFINITION_FILE
> > rm -f $POOL_DEFINITION_FILE
> > virsh pool-autostart $POOL
> > virsh pool-start $POOL
> >
> > I'm then using virt-install to try to create a domain:
> >
> > NAME=testguest
> > DEV=vda
> > SIZE=8G
> > IMAGE=CentOS-7-x86_64-Minimal-1503-01.iso
> > VCPUS=1
> > RAM=512
> > MACLAST_HEX=10
> > IPLAST_DECIMAL=16
> >
> > FILE=$NAME-$DEV
> > qemu-img create -f rbd rbd:$POOL/$FILE $SIZE
> > sudo virt-install \
> > --connect qemu:///system \
> > --virt-type kvm \
> > --name $NAME \
> > --ram $RAM \
> > --vcpus=$VCPUS \
> > --disk vol=$POOL/$FILE \
> > --location /var/lib/libvirt/images/$IMAGE \
> > --vnc \
> > --noautoconsole \
> > --os-type linux \
> > --os-variant rhel7 \
> > --network=bridge:virbr0,model=virtio,mac=52:54:00:00:00:$MACLAST_HEX \
> > --autostart
> >
> > If I run the above with --print-xml, the generated XML includes the
> following
> > definition for the disk:
> >
> > 
> >   
> >   
> > 
> >   
> >   
> > 
> >
> > This has parsed enough of the pool definition to replace the libvirt
> pool with
> > much of its definition, but has excluded the vital  part.
> >
> > Should virt-install include more of the pool's data here, or less?  I'd
> > naively suggest less and give the user as much freedom as possible to 
> change
> > the pool definition in the future.
> >
> > Has anyone else encountered this problem and is there a known fix for 
> my use
> > case?  I've not found one after reasonably extensive searching, but my
> > Google-fu isn't always perfect.
> >
> > If you're reading this and there is a known fix, can you point me to it?
> >
> 
> Thanks for the report. Known issue, there isn't a fix, but it's on my todo
> list. Might be a month or so though, I need to set up a bunch of network
> storage servers (again)
> 
> - Cole
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Replace the unar to more common archivers

[Cole Robinson]

On 01/05/2016 11:22 PM, Lin Ma wrote:
> Because some of distributions dont provide the unar (universal archiver),
> Using more common archivers to replace it.
> 
> Signed-off-by: Lin Ma 
> ---
>  virtconv/formats.py | 37 ++---
>  1 file changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/virtconv/formats.py b/virtconv/formats.py
> index 9a6d237..ed8a66e 100644
> --- a/virtconv/formats.py
> +++ b/virtconv/formats.py
> @@ -118,6 +118,8 @@ def _find_input(input_file, parser, print_cb):
>  try:
>  ext = os.path.splitext(input_file)[1]
>  tempdir = None
> +binname = None
> +pkg = None
>  if ext and ext[1:] in ["zip", "gz", "ova",
>  "tar", "bz2", "bzip2", "7z", "xz"]:
>  basedir = "/var/tmp"
> @@ -129,19 +131,40 @@ def _find_input(input_file, parser, print_cb):
>  
>  base = os.path.basename(input_file)
>  
> -# check if 'unar' command existed.
> -if not find_executable("unar"):
> +if (ext[1:] == "zip"):
> +binname = "unzip"
> +pkg = "unzip"
> +cmd = ["unzip", "-o", "-d", tempdir, input_file]
> +elif (ext[1:] == "7z"):
> +binname = "7z"
> +pkg = "p7zip"
> +cmd = ["7z", "-o" + tempdir, "e", input_file]
> +elif (ext[1:] == "ova" or ext[1:] == "tar"):
> +binname = "tar"
> +pkg = "tar"
> +cmd = ["tar", "xf", input_file, "-C", tempdir]
> +elif (ext[1:] == "gz"):
> +binname = "gzip"
> +pkg = "gzip"
> +cmd = ["tar", "zxf", input_file, "-C", tempdir]
> +elif (ext[1:] == "bz2" or ext[1:] == "bzip2"):
> +binname = "bzip2"
> +pkg = "bzip2"
> +cmd = ["tar", "jxf", input_file, "-C", tempdir]
> +elif (ext[1:] == "xz"):
> +binname = "xz"
> +pkg = "xz"
> +cmd = ["tar", "Jxf", input_file, "-C", tempdir]
> +if not find_executable(binname):
>  raise RuntimeError(_("%s appears to be an archive, "
> -"but 'unar' is not installed. "
> -"Please either install 'unar', or extract the archive "
> +"but '%s' is not installed. "
> +"Please either install '%s', or extract the archive "
>  "yourself and point virt-convert at "
> -"the extracted directory.") % base)
> +"the extracted directory.") % (base, pkg, pkg))
>  
> -cmd = ["unar", "-o", tempdir, base]
>  print_cb(_("%s appears to be an archive, running: %s") %
>  (base, " ".join(cmd)))
>  
> -cmd[-1] = input_file
>  _run_cmd(cmd)
>  force_clean.append(tempdir)
>  input_file = tempdir
> 

This mostly looks good, but I'd like to keep the unar code path as well. I'll
poke at it tomorrow

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Configuring virt-manager (v0.9.0) from the command line

[Cole Robinson]

On 01/10/2016 04:05 PM, Digimer wrote:
> Hi all,
> 
>   I've got a little web-based front end for managing high-availability
> clusters hosting KVM VMs. We use little rhel/centos 6 appliances for
> users to connect to the VMs using virt-manager.
> 
>   I would like to configure virt-manager to add/remove nodes (hosts) as
> needed, but I can't seem to get this to work if virt-manager is already
> running. If it's NOT running, I can either use gconftool-2 or directly
> create/edit the ~/.gconf/apps/virt-manager files and the next time
> virt-manager starts, the correct config is there.
> 
>   I would like to check to see if virt-manager is running and, if so,
> somehow update it with the new configuration. Is this possible?

No, it's not possible with virt-manager 0.9.0 or upstream. It could be
implemented based on watching gconf for added/removed connections, but it
would require a patch.

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Configuring virt-manager (v0.9.0) from the command line

[Cole Robinson]

On 01/10/2016 04:12 PM, Digimer wrote:
> On 10/01/16 04:08 PM, Cole Robinson wrote:
>> On 01/10/2016 04:05 PM, Digimer wrote:
>>> Hi all,
>>>
>>>   I've got a little web-based front end for managing high-availability
>>> clusters hosting KVM VMs. We use little rhel/centos 6 appliances for
>>> users to connect to the VMs using virt-manager.
>>>
>>>   I would like to configure virt-manager to add/remove nodes (hosts) as
>>> needed, but I can't seem to get this to work if virt-manager is already
>>> running. If it's NOT running, I can either use gconftool-2 or directly
>>> create/edit the ~/.gconf/apps/virt-manager files and the next time
>>> virt-manager starts, the correct config is there.
>>>
>>>   I would like to check to see if virt-manager is running and, if so,
>>> somehow update it with the new configuration. Is this possible?
>>
>> No, it's not possible with virt-manager 0.9.0 or upstream. It could be
>> implemented based on watching gconf for added/removed connections, but it
>> would require a patch.
>>
>> - Cole
> 
> So as it stands now, I should check to see if it is running and, if so,
> close it before making the changes and restart?
> 

Yeah that's the only option I can think.

> I think it would be a great feature to have, fwiw. :)
> 

Shouldn't be too hard to implement ;) We already have gconf/gsettings watches
elsewhere in the code for simpler options. If you wanna take a stab at a patch
I can give guidance

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] Replace the unar to more common archivers

[Cole Robinson]

On 01/07/2016 10:55 PM, Cole Robinson wrote:
> On 01/05/2016 11:22 PM, Lin Ma wrote:
>> Because some of distributions dont provide the unar (universal archiver),
>> Using more common archivers to replace it.
>>
>> Signed-off-by: Lin Ma 
>> ---
>>  virtconv/formats.py | 37 ++---
>>  1 file changed, 30 insertions(+), 7 deletions(-)
>>
>> diff --git a/virtconv/formats.py b/virtconv/formats.py
>> index 9a6d237..ed8a66e 100644
>> --- a/virtconv/formats.py
>> +++ b/virtconv/formats.py
>> @@ -118,6 +118,8 @@ def _find_input(input_file, parser, print_cb):
>>  try:
>>  ext = os.path.splitext(input_file)[1]
>>  tempdir = None
>> +binname = None
>> +pkg = None
>>  if ext and ext[1:] in ["zip", "gz", "ova",
>>  "tar", "bz2", "bzip2", "7z", "xz"]:
>>  basedir = "/var/tmp"
>> @@ -129,19 +131,40 @@ def _find_input(input_file, parser, print_cb):
>>  
>>  base = os.path.basename(input_file)
>>  
>> -# check if 'unar' command existed.
>> -if not find_executable("unar"):
>> +if (ext[1:] == "zip"):
>> +binname = "unzip"
>> +pkg = "unzip"
>> +cmd = ["unzip", "-o", "-d", tempdir, input_file]
>> +elif (ext[1:] == "7z"):
>> +binname = "7z"
>> +pkg = "p7zip"
>> +cmd = ["7z", "-o" + tempdir, "e", input_file]
>> +elif (ext[1:] == "ova" or ext[1:] == "tar"):
>> +binname = "tar"
>> +pkg = "tar"
>> +cmd = ["tar", "xf", input_file, "-C", tempdir]
>> +elif (ext[1:] == "gz"):
>> +binname = "gzip"
>> +pkg = "gzip"
>> +cmd = ["tar", "zxf", input_file, "-C", tempdir]
>> +elif (ext[1:] == "bz2" or ext[1:] == "bzip2"):
>> +binname = "bzip2"
>> +pkg = "bzip2"
>> +cmd = ["tar", "jxf", input_file, "-C", tempdir]
>> +elif (ext[1:] == "xz"):
>> +binname = "xz"
>> +pkg = "xz"
>> +cmd = ["tar", "Jxf", input_file, "-C", tempdir]
>> +if not find_executable(binname):
>>  raise RuntimeError(_("%s appears to be an archive, "
>> -"but 'unar' is not installed. "
>> -"Please either install 'unar', or extract the archive "
>> +"but '%s' is not installed. "
>> +"Please either install '%s', or extract the archive "
>>  "yourself and point virt-convert at "
>> -"the extracted directory.") % base)
>> +"the extracted directory.") % (base, pkg, pkg))
>>  
>> -cmd = ["unar", "-o", tempdir, base]
>>  print_cb(_("%s appears to be an archive, running: %s") %
>>  (base, " ".join(cmd)))
>>  
>> -cmd[-1] = input_file
>>  _run_cmd(cmd)
>>  force_clean.append(tempdir)
>>  input_file = tempdir
>>
> 
> This mostly looks good, but I'd like to keep the unar code path as well. I'll
> poke at it tomorrow
> 

Actually it doesn't seem to make much sense, the patch covers all the formats
we previously whitelist, so I just pushed it as is (with a small change to the
test output) Thanks!

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] manager: show reason together with domain state

[Cole Robinson]

On 01/12/2016 03:50 AM, Pavel Hrdina wrote:
> We display this information in the detail page, so let's display it also
> in the manager page.
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  virtManager/manager.py | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/virtManager/manager.py b/virtManager/manager.py
> index 3b908ee..3a14a2b 100644
> --- a/virtManager/manager.py
> +++ b/virtManager/manager.py
> @@ -645,6 +645,9 @@ class vmmManager(vmmGObjectUI):
>  else:
>  name = vm.get_name_or_title()
>  status = vm.run_status()
> +reason = vm.run_status_reason()
> +if reason:
> +status = "%s (%s)" % (status, reason)
>  markup = self._build_vm_markup(name, status)
>  status_icon = vm.run_status_icon_name()
>  hint = vm.get_description()
> @@ -747,6 +750,9 @@ class vmmManager(vmmGObjectUI):
>  
>  name = vm.get_name_or_title()
>  status = vm.run_status()
> +reason = vm.run_status_reason()
> +if reason:
> +status = "%s (%s)" % (status, reason)
>  
>  row[ROW_SORT_KEY] = name
>  row[ROW_STATUS_ICON] = vm.run_status_icon_name()
> 

Hmm. I'm kinda hesitant here because many of reasons (or their labels) are
confusing:

Confusing:
  Paused (User)
  Shutdown (Destroyed)

Now, you and I understand what those all mean, but I guarantee some users will
ask questions. And then there's all the uninteresting states like:

  Running (Unpaused)
  Saves (Saved)
  Running (Restored)

That said I understand some state reasons are very useful, like pausing on IO
error, or any reason the VM crashed. So I think we should whitelist the states
we show in manager window to only be those of particular relevance, like
uncommon events. The details window can continue to show everything

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager just sits at Connecting...

[Cole Robinson]

On 01/14/2016 11:39 AM, Greg Teiber wrote:
> Hello Everyone,
> 
>  
> 
> I didn’t see an archive search function…  So here we go. 
> 

There isn't one. But if you google 'virt-tools-list ' it's
pretty close

>  
> 
> When I open virt-manager it opens up, and sits there with “QEMU/KVM –
> Connecting…”  And doesn’t advance. 
> 
> When I first installed this machine, VMM was able to open, and I was able to
> create guests.  However, I was unable to view their consoles.  After rebooting
> the host, now VMM seems unable to connect. 
> 
>  
> 
> I’ve verified that qemu is running.  If I do virsh – connect qemu:///system
> list  I do see the list of created guests.  And I can even start them from the
> command line. 
> 
> I’m running centos 7.  The console I’m logged into is a non privileged user. 
> I open a terminal and launch VMM as root. 
> 

How are you launching it as root? Exact command please. sudo, su, su -, su -c,
etc.

Generally running a UI app as root from a regular desktop session can cause
all sorts of issues with dbus access. Better to run virt-manager as a regular
user, then feed it your root password via the polkit prompt.

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager just sits at Connecting...

[Cole Robinson]

On 01/14/2016 11:51 AM, Greg Teiber wrote:
> I'll give the google route a shot.
> 
> I su, and become root in the terminal.  Then type virt-manager.  
> 
> [sa@vm02 ~]$ su
> Password:

For one thing you pretty much never want to run plain 'su' if trying to launch
a modern desktop app. Use 'su -', which invokes a full login shell, giving
root it's own environment, etc. This has caused issues with virt-manager in
the past

Also, are you at the physical machine, or running over ssh ?

> [root@vm02 sa]# virt-manager
> 
> I have tried running virt-manager and giving it the root password when it 
> opens.  I get the same result, where it just sits there "Connecting..."
> 

Try running virt-manager --debug and see what output it shows when it hangs,
maybe there's some obvious error that needs fixing.

> 
> 
> -Original Message-
> From: Cole Robinson [mailto:crobi...@redhat.com] 
> Sent: Thursday, January 14, 2016 10:45 AM
> To: Greg Teiber; virt-tools-list@redhat.com
> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
> 
> On 01/14/2016 11:39 AM, Greg Teiber wrote:
>> Hello Everyone,
>>
>>  
>>
>> I didn't see an archive search function...  So here we go. 
>>
> 
> There isn't one. But if you google 'virt-tools-list ' it's 
> pretty close
> 
>>  
>>
>> When I open virt-manager it opens up, and sits there with "QEMU/KVM - 
>> Connecting..."  And doesn't advance.
>>
>> When I first installed this machine, VMM was able to open, and I was 
>> able to create guests.  However, I was unable to view their consoles.  
>> After rebooting the host, now VMM seems unable to connect.
>>
>>  
>>
>> I've verified that qemu is running.  If I do virsh - connect 
>> qemu:///system list  I do see the list of created guests.  And I can 
>> even start them from the command line.
>>
>> I'm running centos 7.  The console I'm logged into is a non privileged user. 
>> I open a terminal and launch VMM as root. 
>>
> 
> How are you launching it as root? Exact command please. sudo, su, su -, su 
> -c, etc.
> 
> Generally running a UI app as root from a regular desktop session can cause 
> all sorts of issues with dbus access. Better to run virt-manager as a regular 
> user, then feed it your root password via the polkit prompt.
> 
> - Cole
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager just sits at Connecting...

[Cole Robinson]

On 01/14/2016 04:57 PM, Greg Teiber wrote:
> I'm using VNC to get to the desktop on a physical server.  
> 
> I tried it with su - and no joy.  So I tried virt-manager --debug  
> 
> I got back a couple pages of this: 
> 
> " Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/baseclass.py", line 135, in 
> wrap_func
> self.disconnect(id_list[0])
>   File "/usr/share/virt-manager/virtManager/baseclass.py", line 96, in 
> disconnect
> ret = GObject.GObject.disconnect(self, handle)
>   File "/usr/lib64/python2.7/site-packages/gi/overrides/GObject.py", line 
> 429, in wrapper
> return func(_get_instance_for_signal(obj), *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in function
> return info.invoke(*args, **kwargs)
> TypeError: argument instance: Expected GObject.Object, but got PyCObject"
> 
> That's an obvious problem, but I'm not sure what direction to go in repairing 
> it.
> 

Me neither, that's a new one to me. What version of centos is this? Please
provide:

rpm -q virt-manager gtk3 pygobject3

Thanks,
Cole

> -Greg
> 
> -Original Message-
> From: Cole Robinson [mailto:crobi...@redhat.com] 
> Sent: Thursday, January 14, 2016 10:56 AM
> To: Greg Teiber; virt-tools-list@redhat.com
> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
> 
> On 01/14/2016 11:51 AM, Greg Teiber wrote:
>> I'll give the google route a shot.
>>
>> I su, and become root in the terminal.  Then type virt-manager.  
>>
>> [sa@vm02 ~]$ su
>> Password:
> 
> For one thing you pretty much never want to run plain 'su' if trying to 
> launch a modern desktop app. Use 'su -', which invokes a full login shell, 
> giving root it's own environment, etc. This has caused issues with 
> virt-manager in the past
> 
> Also, are you at the physical machine, or running over ssh ?
> 
>> [root@vm02 sa]# virt-manager
>>
>> I have tried running virt-manager and giving it the root password when it 
>> opens.  I get the same result, where it just sits there "Connecting..."
>>
> 
> Try running virt-manager --debug and see what output it shows when it hangs, 
> maybe there's some obvious error that needs fixing.
> 
>>
>>
>> -Original Message-
>> From: Cole Robinson [mailto:crobi...@redhat.com]
>> Sent: Thursday, January 14, 2016 10:45 AM
>> To: Greg Teiber; virt-tools-list@redhat.com
>> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
>>
>> On 01/14/2016 11:39 AM, Greg Teiber wrote:
>>> Hello Everyone,
>>>
>>>  
>>>
>>> I didn't see an archive search function...  So here we go. 
>>>
>>
>> There isn't one. But if you google 'virt-tools-list ' 
>> it's pretty close
>>
>>>  
>>>
>>> When I open virt-manager it opens up, and sits there with "QEMU/KVM - 
>>> Connecting..."  And doesn't advance.
>>>
>>> When I first installed this machine, VMM was able to open, and I was 
>>> able to create guests.  However, I was unable to view their consoles.
>>> After rebooting the host, now VMM seems unable to connect.
>>>
>>>  
>>>
>>> I've verified that qemu is running.  If I do virsh - connect 
>>> qemu:///system list  I do see the list of created guests.  And I can 
>>> even start them from the command line.
>>>
>>> I'm running centos 7.  The console I'm logged into is a non privileged 
>>> user. 
>>> I open a terminal and launch VMM as root. 
>>>
>>
>> How are you launching it as root? Exact command please. sudo, su, su -, su 
>> -c, etc.
>>
>> Generally running a UI app as root from a regular desktop session can cause 
>> all sorts of issues with dbus access. Better to run virt-manager as a 
>> regular user, then feed it your root password via the polkit prompt.
>>
>> - Cole
>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager just sits at Connecting...

[Cole Robinson]

Is your machine fully updated? My RHEL7 machine has those versions of
virt-manager and gtk3, but it has new pygobject3-3.14.0-3.el7.x86_64 . Try
updating to that

- Cole

On 01/15/2016 11:24 AM, Greg Teiber wrote:
> Cole, you're being an amazing resource.  Thank you.  
> 
> It's centos7
> 
> rpm -q virt-manager gtk3 pygobject3
> 
> virt-manager-1.2.1-8.el7.noarch
> gtk3-3.14.13-16.el7.x86_64
> pygobject3-3.8.2-6.el7.x86_64
> 
> -Greg
> 
> -Original Message-
> From: Cole Robinson [mailto:crobi...@redhat.com] 
> Sent: Thursday, January 14, 2016 5:54 PM
> To: Greg Teiber; virt-tools-list@redhat.com
> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
> 
> On 01/14/2016 04:57 PM, Greg Teiber wrote:
>> I'm using VNC to get to the desktop on a physical server.  
>>
>> I tried it with su - and no joy.  So I tried virt-manager --debug
>>
>> I got back a couple pages of this: 
>>
>> " Traceback (most recent call last):
>>   File "/usr/share/virt-manager/virtManager/baseclass.py", line 135, in 
>> wrap_func
>> self.disconnect(id_list[0])
>>   File "/usr/share/virt-manager/virtManager/baseclass.py", line 96, in 
>> disconnect
>> ret = GObject.GObject.disconnect(self, handle)
>>   File "/usr/lib64/python2.7/site-packages/gi/overrides/GObject.py", line 
>> 429, in wrapper
>> return func(_get_instance_for_signal(obj), *args, **kwargs)
>>   File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in 
>> function
>> return info.invoke(*args, **kwargs)
>> TypeError: argument instance: Expected GObject.Object, but got PyCObject"
>>
>> That's an obvious problem, but I'm not sure what direction to go in 
>> repairing it.
>>
> 
> Me neither, that's a new one to me. What version of centos is this? Please
> provide:
> 
> rpm -q virt-manager gtk3 pygobject3
> 
> Thanks,
> Cole
> 
>> -Greg
>>
>> -Original Message-
>> From: Cole Robinson [mailto:crobi...@redhat.com]
>> Sent: Thursday, January 14, 2016 10:56 AM
>> To: Greg Teiber; virt-tools-list@redhat.com
>> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
>>
>> On 01/14/2016 11:51 AM, Greg Teiber wrote:
>>> I'll give the google route a shot.
>>>
>>> I su, and become root in the terminal.  Then type virt-manager.  
>>>
>>> [sa@vm02 ~]$ su
>>> Password:
>>
>> For one thing you pretty much never want to run plain 'su' if trying 
>> to launch a modern desktop app. Use 'su -', which invokes a full login 
>> shell, giving root it's own environment, etc. This has caused issues 
>> with virt-manager in the past
>>
>> Also, are you at the physical machine, or running over ssh ?
>>
>>> [root@vm02 sa]# virt-manager
>>>
>>> I have tried running virt-manager and giving it the root password when it 
>>> opens.  I get the same result, where it just sits there "Connecting..."
>>>
>>
>> Try running virt-manager --debug and see what output it shows when it hangs, 
>> maybe there's some obvious error that needs fixing.
>>
>>>
>>>
>>> -Original Message-
>>> From: Cole Robinson [mailto:crobi...@redhat.com]
>>> Sent: Thursday, January 14, 2016 10:45 AM
>>> To: Greg Teiber; virt-tools-list@redhat.com
>>> Subject: Re: [virt-tools-list] Virt-manager just sits at Connecting...
>>>
>>> On 01/14/2016 11:39 AM, Greg Teiber wrote:
>>>> Hello Everyone,
>>>>
>>>>  
>>>>
>>>> I didn't see an archive search function...  So here we go. 
>>>>
>>>
>>> There isn't one. But if you google 'virt-tools-list ' 
>>> it's pretty close
>>>
>>>>  
>>>>
>>>> When I open virt-manager it opens up, and sits there with "QEMU/KVM 
>>>> - Connecting..."  And doesn't advance.
>>>>
>>>> When I first installed this machine, VMM was able to open, and I was 
>>>> able to create guests.  However, I was unable to view their consoles.
>>>> After rebooting the host, now VMM seems unable to connect.
>>>>
>>>>  
>>>>
>>>> I've verified that qemu is running.  If I do virsh - connect 
>>>> qemu:///system list  I do see the list of created guests.  And I can 
>>>> even start them from the command line.
>>>>
>>>> I'm running centos 7.  The console I'm logged into is a non privileged 
>>>> user. 
>>>> I open a terminal and launch VMM as root. 
>>>>
>>>
>>> How are you launching it as root? Exact command please. sudo, su, su -, su 
>>> -c, etc.
>>>
>>> Generally running a UI app as root from a regular desktop session can cause 
>>> all sorts of issues with dbus access. Better to run virt-manager as a 
>>> regular user, then feed it your root password via the polkit prompt.
>>>
>>> - Cole
>>>
>>
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 3/3] virtconvtest: Fix vmx2libvirt test

[Cole Robinson]

On 01/15/2016 02:27 AM, Michal Privoznik wrote:
> The test consists of translating VMX configuration into domain
> XML and converting disks. Cool. But the disk is zipped in a file
> and the test tries to string match unzipping command. Problem is,
> the absolute path is passed to the unzip command which makes it
> impossible for the test to succeed on other hosts.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt | 2 +-
>  tests/virtconvtest.py| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt 
> b/tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt
> index b046c66..b13662c 100644
> --- a/tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt
> +++ b/tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt
> @@ -73,5 +73,5 @@
>  
>  
>  
> -test-vmx-zip.zip appears to be an archive, running: unzip -o -d 
> /var/tmp/virt-convert-tmp 
> /home/crobinso/src/virt-manager/tests/virtconv-files/vmx_input/test-vmx-zip.zip
> +test-vmx-zip.zip appears to be an archive, running: unzip -o -d 
> /var/tmp/virt-convert-tmp vmx_input/test-vmx-zip.zip
>  Copying MS-DOS.vmdk to /var/lib/libvirt/images/MS-DOS
> diff --git a/tests/virtconvtest.py b/tests/virtconvtest.py
> index 622117f..859e8e0 100644
> --- a/tests/virtconvtest.py
> +++ b/tests/virtconvtest.py
> @@ -49,7 +49,7 @@ class TestVirtConv(unittest.TestCase):
>  ignore, out_xml = guest.start_install(return_xml=True)
>  out_expect = out_xml
>  if outbuf.getvalue():
> -out_expect += ("\n\n" + outbuf.getvalue())
> +out_expect += ("\n\n" + outbuf.getvalue().replace(base_dir, "" ))
> 

Extra whitespace here. Pushed with that changed, thanks!

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 2/3] virt-convert: Don't detect existing paths in test suite

[Cole Robinson]

On 01/15/2016 02:27 AM, Michal Privoznik wrote:
> We have this option --dry-run that should run through the
> installation process but don't actually touch anything. Just
> pretend the installation. And we have a test that uses it
> heavily. However, the test is failing:
> 
>   Traceback (most recent call last):
> File "/home/zippy/work/virt-manager.git/tests/clitest.py", line 161, in 
> _launch_command
>   ret = virtconvert.main(conn=conn)
> File "virt-convert", line 111, in main
>   destdir=options.destination, dry=options.dry)
> File "/home/zippy/work/virt-manager.git/virtconv/formats.py", line 314, 
> in convert_disks
>   newpath)
>   RuntimeError: New path name '/var/lib/libvirt/images/fedora.qcow2' already 
> exists
> 
> Problem is, even in test suite we really touch the host paths.
> This in general will spit unpredictable results. Resolution
> consists of making this specific part of the code fault tolerant
> if ran under test suite.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  virtconv/formats.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virtconv/formats.py b/virtconv/formats.py
> index ed8a66e..a7f88cb 100644
> --- a/virtconv/formats.py
> +++ b/virtconv/formats.py
> @@ -309,7 +309,7 @@ class VirtConverter(object):
>  if disk_format:
>  newpath += ("." + disk_format)
>  newpath = os.path.join(destdir, newpath)
> -if os.path.exists(newpath):
> +if os.path.exists(newpath) and not _is_test():
>  raise RuntimeError(_("New path name '%s' already exists") %
>  newpath)
>  
> 

Thanks, pushed

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 1/3] tests: Update virt-install-many-devices.xml

[Cole Robinson]

On 01/15/2016 02:27 AM, Michal Privoznik wrote:
> Libvirt started to put type='raw' to  element to disks
> when no type has been provided. We should reflect that change in
> our tests too.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  tests/cli-test-xml/compare/virt-install-many-devices.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/cli-test-xml/compare/virt-install-many-devices.xml 
> b/tests/cli-test-xml/compare/virt-install-many-devices.xml
> index 79eb189..248a59f 100644
> --- a/tests/cli-test-xml/compare/virt-install-many-devices.xml
> +++ b/tests/cli-test-xml/compare/virt-install-many-devices.xml
> @@ -76,12 +76,12 @@
>
>  
>  
> -  
> +  
>
>
>  
>  
> -  
> +  
>
>  
>
> 

I needed to expand this to skip the test on older libvirt, so I can still run
the test suite on stock f23 for example. It's fixed in git though

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH 0/3] Couple of test fixes

[Cole Robinson]

On 01/15/2016 02:27 AM, Michal Privoznik wrote:
> Finally, I've managed to find time to fix the tests.
> 

Are you running these locally, or did the test failures come from CI
somewhere? I know there was libvirt CI at one point but I forget the details

Thanks,
Cole

> Michal Privoznik (3):
>   tests: Update virt-install-many-devices.xml
>   virt-convert: Don't detect existing paths in test suite
>   virtconvtest: Fix vmx2libvirt test
> 
>  tests/cli-test-xml/compare/virt-install-many-devices.xml | 4 ++--
>  tests/virtconv-files/libvirt_output/vmx2libvirt_test-vmx-zip.libvirt | 2 +-
>  tests/virtconvtest.py| 2 +-
>  virtconv/formats.py  | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] passing metadata to virt-manager or vmm

[Cole Robinson]

On 01/18/2016 01:24 PM, Abdi Ibrahim wrote:
> Just wondering if it is possible to pass metadata to the virt-manager (GUI
> client) instead of using the virsh command.
> 

Outside of the basic bits like description and title, there isn't any
virt-manager support. We should add more support to virt-install/virt-xml
though...

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] passing metadata to virt-manager or vmm

[Cole Robinson]

What types of metadata are you adding?

- Cole

On 01/19/2016 11:00 AM, Abdi Ibrahim wrote:
> Yeah... I'm aware of that but students are given vmm access against
> hypervisors in order to launch instances/domains but no ssh access. Folks are
> from vmware infrastructure where there is a familiarity on vSphere Client with
> all options available on the UI. Will continue with virt-install with custom
> xml file to include any metadata.
> 
> Thanks for the response tho... much appreciated. 
> 
> On Tue, Jan 19, 2016 at 10:56 AM, Cole Robinson  <mailto:crobi...@redhat.com>> wrote:
> 
> On 01/18/2016 01:24 PM, Abdi Ibrahim wrote:
> > Just wondering if it is possible to pass metadata to the virt-manager 
> (GUI
> > client) instead of using the virsh command.
> >
> 
> Outside of the basic bits like description and title, there isn't any
> virt-manager support. We should add more support to virt-install/virt-xml
> though...
> 
> - Cole
> 
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] passing metadata to virt-manager or vmm

[Cole Robinson]

Interesting, sounds cool :) Are these bits a one time setup thing or do they
need to be tweaked for an existing VM?

- Cole

On 01/19/2016 11:10 AM, Abdi Ibrahim wrote:
> ​there is a process running on the hypervisor (kvm in my case) watching for VM
> events (launch, destroy, stop etc...) and reads the domain xml file to trigger
> a configuration management workflow. For example there is a tag for tenant
> name and ID (OpenStack) and when the VM is shutdown or rebooted the process
> notifies a Consul cluster (Hashicorp) for monitoring purposes. Hope this make
> sense. ​
> 
> On Tue, Jan 19, 2016 at 11:03 AM, Cole Robinson  <mailto:crobi...@redhat.com>> wrote:
> 
> What types of metadata are you adding?
> 
> - Cole
> 
> On 01/19/2016 11:00 AM, Abdi Ibrahim wrote:
> > Yeah... I'm aware of that but students are given vmm access against
> > hypervisors in order to launch instances/domains but no ssh access. 
> Folks are
> > from vmware infrastructure where there is a familiarity on vSphere 
> Client with
> > all options available on the UI. Will continue with virt-install with 
> custom
> > xml file to include any metadata.
> >
>     > Thanks for the response tho... much appreciated.
> >
> > On Tue, Jan 19, 2016 at 10:56 AM, Cole Robinson  <mailto:crobi...@redhat.com>
> > <mailto:crobi...@redhat.com <mailto:crobi...@redhat.com>>> wrote:
> >
> > On 01/18/2016 01:24 PM, Abdi Ibrahim wrote:
> > > Just wondering if it is possible to pass metadata to the
> virt-manager (GUI
> > > client) instead of using the virsh command.
> > >
> >
> > Outside of the basic bits like description and title, there isn't 
> any
> > virt-manager support. We should add more support to
> virt-install/virt-xml
> > though...
> >
> > - Cole
> >
> >
> 
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-install: looking for option to get rombar='off' in guest xml

[Cole Robinson]

On 01/19/2016 05:33 PM, P.A.M. van Dam (Pascal) wrote:
> On Tue, Nov 17, 2015 at 09:41:50AM -0500, Cole Robinson wrote:
>> On 11/17/2015 06:03 AM, P.A.M. van Dam (Pascal) wrote:
>>> Good morning all,
>>>
>>> I've one small question. Due to the nature of my tests with UEFI/OVMF and 
>>> iSCSI booting I need to get the
>>> item  (e.g. disable network adapter rom) in my guests xml. 
>>> Editing it by hand is not really my preferred way. Which option(s) should
>>> I give virt-install to realise this for me?
>>>
>>
>> The virt-install/virt-xml option --hostdev rom_bar=on|off
>>
>> You can set it for existing VMs host devices with virt-xml like:
>>
>>   sudo virt-xml $VMNAME --edit all --hostdev rom_bar=off
>>
>> - Cole
> 
> Good evening all,
> 
> Thanks for the answer, but I am afraid it does not work for my case. If I 
> read this correctly it is used for hostdev devices, so devices that get 
> passed through from
> the host to the guest. I need to introduce the "rom_bar=off" attribute to a 
> virtual driver.
> 
> E.g.
> 
> 
>   
>   
>   
>function='0x0'/>
> 
> 
> must become:
> 
> 
>   
>   
>   
>function='0x0'/>
>   
> 
> 
> 
> Preferably by adding an extra option during virt-install. Is this possible?
> 
> Many thanks for your help!
> 

Ah sorry, I didn't realize  also had a  element. There isn't a
way to set it yet but I just added it upstream:

commit 7f7ff0c3449f81a92a7c61fda883fef785155c7b
Author: Cole Robinson 
Date:   Wed Jan 20 10:53:23 2016 -0500

cli: add --network rom_bar and --network rom_file



Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH RFC virtio-win-pkg-scripts 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 01/18/2016 09:15 AM, Roman Kagan wrote:
> As was discussed some time ago on libguestfs ML
> (http://thread.gmane.org/gmane.comp.emulators.guestfs/8341/focus=8576)
> there is a need in a tool that would lay out the Windows guest drivers
> on a filesystem by Windows flavor and architecture in a way that is
> 
> - easy to consume by both humans and programs
> - dependable in the long term
> 
> This patch series brings in the scripts to do this.
> 
> The scripts are based on the idea that the most actual information about
> the suitability of a driver for a particular flavor / architecture is
> contained in the driver's catalog file (in particular, the process of
> ISV or WHQL siging may affect it).
> 
> Since the catalog files are DER-encoded ASN.1 structures the first patch
> introduces a module to extract relevant information from a .cat file
> using PyASN1 library.
> 

Sounds good. Have you tested this against WHQL cat files? Or just those
chipped with the public/fedora drivers?

> The second patch introduces a script that lays out the drivers by
> arch/flavor.
> It assumes that
> 
> - every driver for a particular arch/flavor is contained in a separate
>   directory
> 

This is correct... but in fedora/RHEL we do use hard links to share the same
file across multiple directories, since some drivers are WHQL signed for
multiple windows versions, so keeping a full copy is redundant. I don't think
that matters here though.

(TBH it's difficult to keep all the variables here in my head, so I may be
wrong about things... but once there's more complete patches I'll play with
them and verify my assumptions)

> - the directory contains a single .inf file; the basename of the file is
>   taken as the name of the package
> 
> - the .cat file for the package is in the same directory and has the
>   same basename as the .inf
> 
> - all the files contained in that directory are associated with the
>   driver and go together with it no matter if they are listed in .inf or
>   .cat or not.
> 

Yes I believe these assumptions are correct.


> The virtio-win driver packages I could get my hands on all matched the
> above assumptions.
> 

All in all this sounds good. The code looks fine modulo some style nits that
aren't worth harping over, they can be cleaned up later.

Thanks,
Cole

> [ There's no integration with the rest of the system yet as I'd like to
> receive some comments on these two first. ]
> 
> Roman Kagan (2):
>   add parser for driver catalog files
>   add script to lay out drivers based on their catalog files
> 
>  util/cpdrivers.py | 191 
> ++
>  util/parsecat.py  | 166 +++
>  2 files changed, 357 insertions(+)
>  create mode 100644 util/cpdrivers.py
>  create mode 100644 util/parsecat.py
> 

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH RFC virtio-win-pkg-scripts 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 01/21/2016 04:47 AM, Roman Kagan wrote:
> On Wed, Jan 20, 2016 at 06:33:26PM -0500, Cole Robinson wrote:
>> On 01/18/2016 09:15 AM, Roman Kagan wrote:
>>> As was discussed some time ago on libguestfs ML
>>> (http://thread.gmane.org/gmane.comp.emulators.guestfs/8341/focus=8576)
>>> there is a need in a tool that would lay out the Windows guest drivers
>>> on a filesystem by Windows flavor and architecture in a way that is
>>>
>>> - easy to consume by both humans and programs
>>> - dependable in the long term
>>>
>>> This patch series brings in the scripts to do this.
>>>
>>> The scripts are based on the idea that the most actual information about
>>> the suitability of a driver for a particular flavor / architecture is
>>> contained in the driver's catalog file (in particular, the process of
>>> ISV or WHQL siging may affect it).
>>>
>>> Since the catalog files are DER-encoded ASN.1 structures the first patch
>>> introduces a module to extract relevant information from a .cat file
>>> using PyASN1 library.
>>>
>>
>> Sounds good. Have you tested this against WHQL cat files?
> 
> Yes.  And seem to have found a couple of bugs in there ;)
> 
>> Or just those chipped with the public/fedora drivers?
> 
> With those too.
> 
>>> The second patch introduces a script that lays out the drivers by
>>> arch/flavor.
>>> It assumes that
>>>
>>> - every driver for a particular arch/flavor is contained in a separate
>>>   directory
>>>
>>
>> This is correct... but in fedora/RHEL we do use hard links to share the same
>> file across multiple directories, since some drivers are WHQL signed for
>> multiple windows versions, so keeping a full copy is redundant. I don't think
>> that matters here though.
> 
> The copying script has four modes: full copy, file hardlinks, file
> symlinks (including relative), directory symlinks.  E.g. if you prepare
> stuff for building a cd or a floppy image you'll probably want full
> copy; if lay out things in an rpm you'd rather use one of the linking
> modes.
> 

Gotchya, though ISO can handle hardlinks FYI.

>> (TBH it's difficult to keep all the variables here in my head, so I may be
>> wrong about things... but once there's more complete patches I'll play with
>> them and verify my assumptions)
> 
> Well both scripts are callable so you can play right now.
> 
> E.g. to dump relevant fields from a .cat file:
> 
> # python util/parsecat.py some/where/smth.cat
> 
> To see what would be done with the drivers:
> 
> # python util/cpdrivers.py -n -m symlink contents/of/virtio-win/iso \
>   destination/path
> 

Indeed, I'll try to carve out some time.

>>> - the directory contains a single .inf file; the basename of the file is
>>>   taken as the name of the package
>>>
>>> - the .cat file for the package is in the same directory and has the
>>>   same basename as the .inf
>>>
>>> - all the files contained in that directory are associated with the
>>>   driver and go together with it no matter if they are listed in .inf or
>>>   .cat or not.
>>>
>>
>> Yes I believe these assumptions are correct.
>>
>>
>>> The virtio-win driver packages I could get my hands on all matched the
>>> above assumptions.
>>>
>>
>> All in all this sounds good. The code looks fine modulo some style nits that
>> aren't worth harping over, they can be cleaned up later.
> 
> No prob fixing the style things too, as I'll probably need to resubmit
> the series anyway with proper integration into the rest of the system.
> 

- Switch to argparse (from optparse)
- Run pep8 over the code

That should turn up some things

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH RFC virtio-win-pkg-scripts v2 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 01/22/2016 01:27 PM, Roman Kagan wrote:
> On Fri, Jan 22, 2016 at 06:05:01PM +0300, Roman Kagan wrote:
>> The scripts are based on the idea that the most actual information about
>> the suitability of a driver for a particular flavor / architecture is
>> contained in the driver's catalog file (in particular, the process of
>> ISV or WHQL siging may affect it).
>>
>> Since the catalog files are DER-encoded ASN.1 structures the first patch
>> introduces a module to extract relevant information from a .cat file
>> using PyASN1 library.
>>
>> The second patch introduces a script that lays out the drivers by
>> arch/flavor.
>> It assumes that
>>
>> - every driver for a particular arch/flavor is contained in a separate
>>   directory
>>
>> - the directory contains a single .inf file; the basename of the file is
>>   taken as the name of the package
>>
>> - the .cat file for the package is in the same directory and has the
>>   same basename as the .inf
>>
>> - all the files contained in that directory are associated with the
>>   driver and go together with it no matter if they are listed in the
>>   .inf or in the .cat or not.
>>
>> The virtio-win driver packages I could get my hands on all matched the
>> above assumptions.
>>
>> [ There's no integration with the rest of the system yet as I'd like to
>> sort out some issues first which may affect the logic (in a followup
>> mail). ]
> 
> Now to the issues I'd like to discuss before moving on.
> 
> The current make-*.py scripts can probably be simplified dramatically
> with this new logic.  However they contain a fair amount of consistency
> checks which I'd like to maintain.  Besides, I'd like to figure out
> what's on input and what's the desired output of the process.
> 
> Here's the way I thought of using the submitted scripts (in bash for
> simplicity of explanation):
> 
> 
> set -e
> 
> wrkdir=$(mktemp -d windrvXX)
> dstdir=$wrkdir/virtio-win
> 
> # fetch the drivers (in real life will come from a windows build machine
> # directly)
> curl 
> https://fedorapeople.org/groups/virt/virtio-win/repo/srpms/virtio-win-0.1.112-1.src.rpm
>  |
>   rpm2cpio |
>   cpio -i --to-stdout virtio-win-\*-bin-for-rpm.tar.gz |
>   tar -xzf - -C $wrkdir
> 
> srcdir=$(echo $wrkdir/*)
> 
> rm -fr $srcdir/{*.vfd,vfddrivers}
> 
> # get rid of duplicates (already done for the package in the above srpm
> # but will be needed in general)
> hardlink $srcdir
> 
> # lay out the drivers hardlinking them to the source
> util/cpdrivers.py -m link $srcdir $dstdir/drivers
> 
> # indentify files left behind
> find $srcdir -type f -links +1 -exec rm \{\} \;
> echo "unpackaged files:"
> find $srcdir -type f -printf '%P\n'
> # do something if any is found
> : ...
> 
> # add license, qga, etc. to $dstdir
> : ...
> 
> # create iso image with everything
> mkisofs -o $dstdir/virtio-win.iso -J $dstdir/{drivers,qga}
> 
> # create per-arch/os floppies with basic drivers
> for archdir in $dstdir/drivers/*; do
> arch=${archdir##*/}
> for osdir in $archdir/*; do
> os=${osdir##*/}
> 
>   img=$dstdir/${arch}_{os}.vfd
>   truncate -s 2880k $img
>   mkdosfs $img
>   mcopy -i $img $osdir/{netkvm,vioscsi,viostor}/*.{inf,cat,sys} ::
> # locate and copy txtsetup.oem (dunno if necessary)
> : ...
> done
> done
> 
> # $dstdir is to be found as /usr/share/virtio-win in the resulting rpm
> ==
> 
> The discussion items:
> 
> 1) is it a sensible thing to do in general, with these inputs and
>outputs?
> 

Yes the above sounds reasonable.

> 2) the search for unpackaged files yields some.  E.g. the srpm used
>above gives
> 
>viostor/xp/x86/viostor.sys
>viostor/xp/x86/viostor.inf
>viostor/xp/x86/viostor.pdb
>viostor/xp/x86/viostor.cat
> 
>meaning that there's another viostor driver in the tree which claims
>xp-x86 support.  Indeed, 2k3-x86 driver, being different from xp-x86,
>claims compatibility with both xp and 2k3, and happens to take over.
> 
>There are even more leftovers in the latest RHEL package, that is,
>there are more drivers intersecting in the supported OS lists.
> 

Can you list the RHEL conflicts?

>And I'm afraid this may be a legitimate situation.  Assume a driver
>is signed for, say, 2k8 and 2k8R2, and then a newer version is built
>and signed for 2k8R2 and 2k12.  The script will make arbitrary choice
>of the driver for 2k8R2.  Any suggestion on what to do with this?
> 

Hmm. This is a bit weird. Probably some combination of:

1) plain old packaging error. some wires got crossed and we never updated the
xp driver to share with 2k3 or something similar

2) qe/supportability concerns. maybe the newer 2k3 build was done to fix a 2k3
specific driver, so we only updated 2k3 in the tree to avoid having to re-QE
the xp driver as well. or something in that ballpark.

Maybe vadim knows more, CCd

If #2 is involved I'd rather we work around that some other way: either re-QE
the driver, or o

Re: [virt-tools-list] VMWare guestId to libvirt os-variant

[Cole Robinson]

On 01/23/2016 10:36 AM, mkov wrote:
> Hello,
> Please, help me to figure out how to convert VMWare guestId to libvirt
> os-variant.
> For example,
> 
> guestosid:
> centos64Guest 
> centosGuest   
> 
> os-variant:
> centos6.0
> centos6.1
> centos6.2
> centos6.3
> centos6.4
> centos6.5
> centos7.0
> 

There isn't any easy way to convert. We could track it in libosinfo but the
vmware bits are quite fine grained. I'm not sure what configuration bits
vmware will change depending on the guestosid, we would need to figure that
out first to know what it properly maps to for libosinfo/virt-install defaults.

> The task is to start VM on KVM from disk image fom VMWare. But,
> What is the best to set up as --os-variant in virt-install?
> 
> I will use --import with virt-install. Are these options using together
> (--os-variant and --import)?
> 

Yes they work fine.

> What exactly do --os-variant, how to test it?
> 

--os-variant is used to decide what configuration defaults we will set for the
VM. The classic example is using virtio disk/net for OS that support it
(basically all centos 6+ in this case).

If you want to test it, use the --print-xml option to see how the defaults
change with and without --os-variant

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Delayed Deletion or Creation

[Cole Robinson]

On 01/24/2016 08:15 AM, Michael A Cooper wrote:
> Hey Guys,
> 
> How is everyone? I am not sure how to word this question but here
> goes. I have a 3 server setup and I created a nfs share so that I could do
> Live Migration across the servers. So when I create the vm with qcow2
> everything goes smooth and quick, but when I try to create with .img (Raw) it
> takes forever to create the file. Also when I try and delete an .img file (20
> gb) it has been over 20 minutes to delete it, any ideas?
> 

qcow2 files are sparse/not-fully-allocated, so while you request 20GB it's
probably only writing a few MB. The rest is filled in as the VM writes to it.

raw can do sparse as well, but 1) virt-manager doesn't default to it if you
choose raw which means it is allocating the full 20GB, and 2) even if you do
choose sparse the semantics are a bit different for NFS, not sure if it
affects your use case though:
https://serverfault.com/questions/731632/does-nfs-and-smb-support-sparse-files

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] VMWare guestId to libvirt os-variant

[Cole Robinson]

On 01/26/2016 05:42 AM, MK KM wrote:
> Cole, thank you for answers!
> Could you please tell about:
> 
> 2016-01-25 17:19 GMT+02:00 Cole Robinson  <mailto:crobi...@redhat.com>>:
> 
> On 01/23/2016 10:36 AM, mkov wrote:
> > Hello,
> > Please, help me to figure out how to convert VMWare guestId to libvirt
> > os-variant.
> > For example,
> >
> > guestosid:
> > centos64Guest
> > centosGuest
> >
> > os-variant:
> > centos6.0
> > centos6.1
> > centos6.2
> > centos6.3
> > centos6.4
> > centos6.5
> > centos7.0
> >
> 
> There isn't any easy way to convert. We could track it in libosinfo but 
> the
> vmware bits are quite fine grained. I'm not sure what configuration bits
> vmware will change depending on the guestosid, we would need to figure 
> that
> out first to know what it properly maps to for libosinfo/virt-install
> defaults.
> 
> 
> - Can we use name of OS in os-variant without minor version, like just
> centos6, centos7, rhel7? Output of command "osinfo-query os" has only exact
> version of OS, but I met examples with OS just with major version. Does it
> correct, will it work? 
> 

I can't say for certain, because I don't know what configuration bits the
vmware OS value sets on their side. You will have to test it and see.

> 
> > The task is to start VM on KVM from disk image fom VMWare. But,
> > What is the best to set up as --os-variant in virt-install?
> >
> > I will use --import with virt-install. Are these options using together
> > (--os-variant and --import)?
> >
> 
> Yes they work fine.
> 
> > What exactly do --os-variant, how to test it?
> >
> 
> --os-variant is used to decide what configuration defaults we will set 
> for the
> VM. The classic example is using virtio disk/net for OS that support it
> (basically all centos 6+ in this case).
> 
> If you want to test it, use the --print-xml option to see how the defaults
> change with and without --os-variant
> 
> - Cole
> 
> - What is better option for os-variant, when "osinfo-query os" does not
> contain some version of OS, for example "fedora23"? Does need use fedora22 or
> "auto" or..?

In that case, use whatever the latest fedora version is.

> - How does parameter "auto" work? Will it work for for converted images from
> VMware?

No it won't handle the vmware bit. 'auto' just means 'try to detect a
libosinfo ID from the passed install media'. It in fact doesn't do anything
for --import

> - What is the best way to determine OS from VMware? virt-inspector or somehow
> else?
> I did not find in documentation these information.
> Thanks in advance!

If you have a disk image and you need to do this generically, virt-inspector
is really your only option.

However if you are trying to do this generically and not as a one off, check
out virt-v2v, it might be what you are looking for

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] VMWare guestId to libvirt os-variant

[Cole Robinson]

On 01/27/2016 12:45 PM, Richard W.M. Jones wrote:
> On Tue, Jan 26, 2016 at 11:00:49AM -0500, Cole Robinson wrote:
>> In that case, use whatever the latest fedora version is.
> 
> I always thought it would be nice if virt-install substituted (eg)
> fedora22 instead of fedora23 whenever it encounters a version that it
> doesn't yet know about.
> 

It tries to with fedora. URL detection works well, and libosinfo should return
fedora-unknown which we map to latest fedora version.

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] virtinst: Support paths to SUSE OVMF firmwares

[Cole Robinson]

On 01/27/2016 09:51 PM, Jim Fehlig wrote:
> Extend the domcapabilities regex to include SUSE's OVMF
> file naming convention.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  virtinst/domcapabilities.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/virtinst/domcapabilities.py b/virtinst/domcapabilities.py
> index 86bdfe8..f074b4e 100644
> --- a/virtinst/domcapabilities.py
> +++ b/virtinst/domcapabilities.py
> @@ -101,6 +101,7 @@ class DomainCapabilities(XMLBuilder):
>  "x86_64": [
>  ".*OVMF_CODE\.fd",  # RHEL
>  ".*ovmf-x64/OVMF.*\.fd",  # gerd's firmware repo
> +".*ovmf-x86_64-.*", # SUSE
>  ],
>  "aarch64": [
>  ".*AAVMF_CODE\.fd",  # RHEL
> 

ACK and pushed, thanks! Patches like this are definitely appreciated for
upstream, since ideally virt-manager.git works out of the box on any distro.

"gerd's firmware repo" probably sounds weird, but it's the recommended way to
consume ovmf on fedora, since we can't package it yet due to Fedora's license
policies. Details here if you're curious:

https://fedoraproject.org/wiki/Using_UEFI_with_QEMU

Unfortunately having to hardcode this stuff in the tools is suboptimal,
hopefully long term we figure out a better solution at the libvirt level. I
blogged a bit about it a few weeks ago:

http://blog.wikichoon.com/2016/01/uefi-support-in-virt-install-and-virt.html

also ccing rjones since he has similar code in libguestfs that may need to be
extended

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager][PATCH] test: Adapt to new libvirt

[Cole Robinson]

On 01/29/2016 05:16 AM, Michal Privoznik wrote:
> In libvirt commit 36785c7e775f3 the input devices are no longer
> added by default in XML parsing phase rather than on domain
> startup. However, we are not starting a domain just merely
> playing around with its definition. Therefore we should adjust
> expected outputs.
> 
> Signed-off-by: Michal Privoznik 
> ---
> 
> So the libvirt commit I'm referring to is not yet part of any release. Having
> said that, is this the right way to fix the problem?
> 

Hmm, kindof. I try to keep the test suite working (not failing) on latest
fedora packages. with this change the tests would work on libvirt.git/1.3.2+
but fail for everything else.

Normally in these cases I'll add a bit to the affected test cases that says
'skip this test unless libvirt >= $VERSION'. grep for compare_check in
tests/clitest.py .

I tried coming up with a way to alter testdriver.xml so it would work in both
cases, but indeed the libvirt  XML output was sufficiently weird before
that latest commit that there isn't any way to make it work.

So I've applied your patch, and added this additional commit, see attached.

Thanks,
Cole
>From 2c0157ca9e6a5f8dfb271e2ef4a9731213b00a6a Mon Sep 17 00:00:00 2001
Message-Id: <2c0157ca9e6a5f8dfb271e2ef4a9731213b00a6a.1454099581.git.crobi...@redhat.com>
From: Cole Robinson 
Date: Fri, 29 Jan 2016 15:32:31 -0500
Subject: [PATCH virt-manager] clitest: Skip updated tests on older libvirt

---
 tests/clitest.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/clitest.py b/tests/clitest.py
index fb160ad..cab6232 100644
--- a/tests/clitest.py
+++ b/tests/clitest.py
@@ -829,11 +829,11 @@ c.add_compare("--pm suspend_to_mem=yes,suspend_to_disk=no", "edit-simple-pm")
 c.add_compare("--disk /dev/zero,perms=ro,startup_policy=optional", "edit-simple-disk")
 c.add_compare("--disk path=", "edit-simple-disk-remove-path")
 c.add_compare("--network source=br0,type=bridge,model=virtio,mac=", "edit-simple-network")
-c.add_compare("--graphics tlsport=5902,keymap=ja", "edit-simple-graphics")
+c.add_compare("--graphics tlsport=5902,keymap=ja", "edit-simple-graphics", compare_check="1.3.2") # compare_check= reordering
 c.add_compare("--controller index=15,model=lsilogic", "edit-simple-controller")
 c.add_compare("--smartcard type=spicevmc", "edit-simple-smartcard")
 c.add_compare("--redirdev type=spicevmc,server=example.com:12345", "edit-simple-redirdev")
-c.add_compare("--tpm path=/dev/tpm", "edit-simple-tpm")
+c.add_compare("--tpm path=/dev/tpm", "edit-simple-tpm", compare_check="1.3.2") # compare_check= reordering
 c.add_compare("--rng rate_bytes=,rate_period=", "edit-simple-rng")
 c.add_compare("--watchdog action=reset", "edit-simple-watchdog")
 c.add_compare("--memballoon model=none", "edit-simple-memballoon")
@@ -843,7 +843,7 @@ c.add_compare("--channel null", "edit-simple-channel")
 c.add_compare("--console name=foo.bar.baz", "edit-simple-console")
 c.add_compare("--filesystem /1/2/3,/4/5/6,mode=mapped", "edit-simple-filesystem")
 c.add_compare("--video cirrus", "edit-simple-video", compare_check=support.SUPPORT_CONN_VIDEO_NEW_RAM_OUTPUT)
-c.add_compare("--sound pcspk", "edit-simple-soundhw")
+c.add_compare("--sound pcspk", "edit-simple-soundhw", compare_check="1.3.2") # compare_check= reordering
 c.add_compare("--host-device 0x0781:0x5151,driver_name=vfio", "edit-simple-host-device")
 
 c = vixml.add_category("edit selection", "test-for-virtxml --print-diff --define", compare_check=support.SUPPORT_CONN_INPUT_KEYBOARD)
-- 
2.5.0

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-manager: show guest IP

[Cole Robinson]

On 02/02/2016 11:16 AM, Matwey V. Kornilov wrote:
> 2016-02-01 16:19 GMT+03:00 Michal Privoznik :
>> On 30.01.2016 17:10, Matwey V. Kornilov wrote:
>>> Hello,
>>>
>>> Is it possible to configure virt-manager to show guest IP somewhere?
>>>
>>> I am running qemu with qemu-guest tools and the following command works
>>> good:
>>>
>>> virsh # qemu-agent-command 5 '{"execute":"guest-network-get-interfaces"}'
>>> {"return":[{"name":"lo","ip-addresses":[{"ip-address-type":"ipv4","ip-address":"127.0.0.1","prefix":8},{"ip-address-type":"ipv6","ip-address":"::1","prefix":128}],"hardware-address":"00:00:00:00:00:00"},{"name":"eth0","ip-addresses":[{"ip-address-type":"ipv4","ip-address":"192.168.185.188","prefix":24},{"ip-address-type":"ipv6","ip-address":"fe80::5054:ff:fecc:cfc3","prefix":64}],"hardware-address":"52:54:00:cc:cf:c3"}]}
>>>
>>> But I would like to see this information in virt-manager GUI like in
>>> some proprietary hypervisor clients.
>>
>> Currently, there is no such option. Patches are welcome :)
>>
> 
> Where is the best place in UI to put networking info in your opinion?
> 

To start, the interface device details in the VM details window, the same
place things like mac address and device model are reported.

>> But as a libvirt developer, I'd like to advertise 'virsh domifaddr'
>> command which does basically the same as you are doing in your example
>> but has one possible data source more.
> 
> Am I right that domifaddr uses same mechanism to fetch the data (when
> qemu:/// is used)?

Yes, it has an option to check the guest agent IIRC.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] localization: mark several strings as translatable

[Cole Robinson]

Comments inline

On 02/05/2016 10:23 AM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
>  virtManager/addhardware.py | 54 +-
>  virtManager/connect.py |  6 ++--
>  virtManager/connectauth.py |  2 +-
>  virtManager/connection.py  |  2 +-
>  virtManager/console.py |  4 +--
>  virtManager/createinterface.py | 24 +++
>  virtManager/details.py | 14 -
>  virtManager/error.py   |  2 +-
>  virtManager/gfxdetails.py  |  4 +--
>  virtManager/host.py| 14 -
>  virtManager/interface.py   |  4 +--
>  virtManager/libvirtobject.py   |  4 +--
>  virtManager/netlist.py |  8 ++---
>  virtManager/preferences.py |  4 +--
>  virtManager/storagelist.py | 10 +++
>  virtinst/cloner.py | 66 
> +-
>  virtinst/devicedisk.py |  4 +--
>  virtinst/devicehostdev.py  |  2 +-
>  virtinst/devicerng.py  |  4 +--
>  virtinst/network.py|  4 +--
>  virtinst/seclabel.py   |  4 +--
>  virtinst/support.py|  2 +-
>  22 files changed, 121 insertions(+), 121 deletions(-)
> 
> diff --git a/virtManager/addhardware.py b/virtManager/addhardware.py
> index d3a69c3..45b0c03 100644
> --- a/virtManager/addhardware.py
> +++ b/virtManager/addhardware.py
> @@ -177,7 +177,7 @@ class vmmAddHardware(vmmGObjectUI):
>  hw_list = self.widget("hw-list")
>  hw_list.set_model(model)
>  
> -hw_col = Gtk.TreeViewColumn("Hardware")
> +hw_col = Gtk.TreeViewColumn(_("Hardware"))
>  hw_col.set_spacing(6)
>  hw_col.set_min_width(165)
>  
> @@ -347,32 +347,32 @@ class vmmAddHardware(vmmGObjectUI):
>  def add_hw_option(name, icon, page, sensitive, errortxt, 
> devtype=None):
>  model.append([name, icon, page, sensitive, errortxt, devtype])
>  
> -add_hw_option("Storage", "drive-harddisk", PAGE_DISK, have_storage,
> +add_hw_option(_("Storage"), "drive-harddisk", PAGE_DISK, 
> have_storage,
>have_storage and storage_tooltip or None)
> -add_hw_option("Controller", "device_pci", PAGE_CONTROLLER, True, 
> None)
> -add_hw_option("Network", "network-idle", PAGE_NETWORK, True, None)
> -add_hw_option("Input", "input-mouse", PAGE_INPUT, self.vm.is_hvm(),
> +add_hw_option(_("Controller"), "device_pci", PAGE_CONTROLLER, True, 
> None)
> +add_hw_option(_("Network"), "network-idle", PAGE_NETWORK, True, None)
> +add_hw_option(_("Input"), "input-mouse", PAGE_INPUT, 
> self.vm.is_hvm(),
>_("Not supported for this guest type."))
> -add_hw_option("Graphics", "video-display", PAGE_GRAPHICS,
> +add_hw_option(_("Graphics"), "video-display", PAGE_GRAPHICS,
>True, None)
> -add_hw_option("Sound", "audio-card", PAGE_SOUND,
> +add_hw_option(_("Sound"), "audio-card", PAGE_SOUND,
>self.vm.is_hvm(),
>_("Not supported for this guest type."))
> -add_hw_option("Serial", Gtk.STOCK_CONNECT, PAGE_CHAR,
> +add_hw_option(_("Serial"), Gtk.STOCK_CONNECT, PAGE_CHAR,
>self.vm.is_hvm(),
>_("Not supported for this guest type."),
>"serial")
> -add_hw_option("Parallel", Gtk.STOCK_CONNECT, PAGE_CHAR,
> +add_hw_option(_("Parallel"), Gtk.STOCK_CONNECT, PAGE_CHAR,
>self.vm.is_hvm(),
>_("Not supported for this guest type."),
>"parallel")
> -add_hw_option("Console", Gtk.STOCK_CONNECT, PAGE_CHAR,
> +add_hw_option(_("Console"), Gtk.STOCK_CONNECT, PAGE_CHAR,
>True, None, "console")
> -add_hw_option("Channel", Gtk.STOCK_CONNECT, PAGE_CHAR,
> +add_hw_option(_("Channel"), Gtk.STOCK_CONNECT, PAGE_CHAR,
>self.vm.is_hvm(),
>_("Not supported for this guest type."),
>"channel")
> -add_hw_option("USB Host Device", "system-run", PAGE_HOSTDEV,
> +add_hw_option(_("USB Host Device"), "system-run", PAGE_HOSTDEV,
>self.conn.is_nodedev_capable(),
>_("Connection does not support host device 
> enumeration"),
>"usb")
> @@ -383,28 +383,28 @@ class vmmAddHardware(vmmGObjectUI):
>  if self.vm.is_container():
>  nodedev_enabled = False
>  nodedev_errstr = _("Not supported for containers")
> -add_hw_option("PCI Host Device", "system-run", PAGE_HOSTDEV,
> +add_hw_option("PCI Host Device"), "system-run", PAGE_HOSTDEV,
>nodedev_enabled, nodedev_errstr, "pci")
>  
> -add_hw_option("Video", "video-display", PAGE_VIDEO, True,
> +add_hw_option(_("Video"), "vi

Re: [virt-tools-list] [virt-manager PATCH v2] localization: mark several strings as translatable

[Cole Robinson]

On 02/06/2016 05:39 AM, Pavel Hrdina wrote:
> On Fri, Feb 05, 2016 at 05:45:13PM +0100, Pavel Hrdina wrote:
> 
> [...]
> 
>> @@ -383,28 +383,28 @@ class vmmAddHardware(vmmGObjectUI):
>>  if self.vm.is_container():
>>  nodedev_enabled = False
>>  nodedev_errstr = _("Not supported for containers")
>> -add_hw_option("PCI Host Device", "system-run", PAGE_HOSTDEV,
>> +add_hw_option("PCI Host Device"), "system-run", PAGE_HOSTDEV,
>>nodedev_enabled, nodedev_errstr, "pci")
>>  
> 
> Consider the _("PCI Host Device") fixed.
> 
> [...]
> 
>> @@ -176,7 +176,7 @@ class vmmConnect(vmmGObjectUI):
>>  model = Gtk.ListStore(str)
>>  model.append(["SSH"])
>>  model.append(["TCP (SASL, Kerberos)"])
>> -model.append(["SSL/TLS with certificates"])
>> +model.append(["SSL/TLS " + _("with certificates)"])
>>  combo.set_model(model)
>>  uiutil.init_combo_text_column(combo, 0)
>>  
> 
> Consider the _("with certificates") fixed.
> 


ACK with those fixes

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 01/25/2016 02:57 PM, Roman Kagan wrote:
> As was discussed some time ago on libguestfs ML
> (http://thread.gmane.org/gmane.comp.emulators.guestfs/8341/focus=8576)
> there is a need in a tool that would lay out the Windows guest drivers
> on a filesystem by Windows flavor and architecture in a way that is
> 
> - easy to consume by both humans and programs
> - dependable in the long term
> 
> This patch series brings in the scripts to do this.
> 
> The scripts are based on the idea that the most actual information about
> the suitability of a driver for a particular flavor / architecture is
> contained in the driver's catalog file (in particular, the process of
> ISV or WHQL siging may affect it).
> 
> Since the catalog files are DER-encoded ASN.1 structures the first patch
> introduces a module to extract relevant information from a .cat file
> using PyASN1 library.
> 
> The second patch introduces a script that lays out the drivers by
> arch/flavor.
> It assumes that
> 
> - every driver for a particular arch/flavor is contained in a separate
>   directory
> 
> - the directory contains a single .inf file; the basename of the file is
>   taken as the name of the package
> 
> - the .cat file for the package is in the same directory and has the
>   same basename as the .inf
> 
> - all the files contained in that directory are associated with the
>   driver and go together with it no matter if they are listed in the
>   .inf or in the .cat or not.
> 
> The virtio-win driver packages I could get my hands on all matched the
> above assumptions.
> 
> Besides, as there occasionally are multiple packages that match a
> particular flavor / arch, the one with the most recent timestamp (taken
> as the signing time if present or the catalog creation time otherwise)
> takes over.
> 
> [ Integration with the rest of the system is still pending ]
> 
> Roman Kagan (2):
>   add parser for driver catalog files
>   add script to lay out drivers based on their catalog files
> 
> ---
> changes since v2:
>  - add extracting of catalog timestamp and signing time
>  - compare the timestamps to decide if the package is to replace the
>already copied one (the most recent wins)
>  - minor refactoring for better readability
> 
> changes since v1:
>  - fix pep8 warnings except for the OS table alignment
>  - add debugging print of what driver package is being processed
>  - switch to argparse
>  - facilitate using as a module
> 
>  util/cpdrivers.py | 238 
>  util/parsecat.py  | 290 
> ++
>  2 files changed, 528 insertions(+)
>  create mode 100644 util/cpdrivers.py
>  create mode 100644 util/parsecat.py
> 

Sorry for the delay, been caught up in other stuff. I'll be focusing on
virtio-win stuff this coming week though

I've committed these patches now. I added a few commits on top to make my
pylint[1] setup happy. No functional changes.

I'm realizing now that the input bits to make-driver-dir.py
(virtio-win/qxl/qemu-ga windows builders from RH's internal build system)
aren't published anywhere so there isn't any way for you to reproduce the full
workflow for the public RPM. I'll work on getting those mirrored on
fedorapeople.org

Thanks,
Cole

[1] https://github.com/crobinso/check-pylint

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] virt-manager SPICE console over ssh

[Cole Robinson]

On 02/15/2016 09:31 AM, Ian Pilcher wrote:
> I am unable to connect to a remote (qemu+ssh://...) SPICE console from
> virt-manager:
> 
>   Error: viewer connection to hypervisor host got refused or
>   disconnected!
> 
> The odd thing is that virt-viewer works just fine when I specify the
> qemu+ssh://... URL on the command line.
> 
> Here is the graphics device in the domain XML:
> 
> 
>   
> 
> 
> Any ideas?
> 

Can you provide virt-manager --debug output? It will show the address the app
is trying to connect to

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] SOLVED: virt-manager SPICE console over ssh

[Cole Robinson]

On 02/15/2016 12:56 PM, Ian Pilcher wrote:
> I knew this rang a bell ...
> 
> The problem was that the SPICE server was configured to listen on the
> wildcard address (0.0.0.0).
> 
> 
>   
> 
> 
> Getting rid of the listen address makes things work.
> 
> 
> 

Makes me wonder what virt-viewer does differently though... maybe it always
tries to use an ssh tunnel if the hypervisor connection is ssh, even if
listen=0.0.0.0 ? I'd need to check

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] countless password requests

[Cole Robinson]

The password prompts are because each remote spice connection requires needs
to open many different channels, each channel will prompt for a password if
you don't have SSH keys setup. So, setup ssh keys like Fabiano suggests. It
will fix your problem

- Cole

On 02/16/2016 11:16 AM, LK wrote:
> Hi Fabiano,
> 
> the password is asked by virt-manager when I try to connect to the remote 
> host.
> After the first request I insert the root password and I can see the list of
> virtual machines on the remote host.
> But, If I try to open one of this virtual machine, virt-manager starts asking
> countless time the root password.
> 
> LK
> 
> Am 14.02.2016 um 20:32 schrieb Fabiano Fidêncio:
>> On Sun, Feb 14, 2016 at 11:37 AM, LK  wrote:
>>> Hi,
>>>
>>> I'm trying to connect to a kvm server running on a remote Fedora 23 host
>>> from an Ubuntu 15.10 host .
>>> The connection is established well and I can see the guest machines running
>>> on the remote  host.
>>> The problem happens when I try to connect to a virtual machine: virt-manager
>>> (1.3.2-0~15.10~ppa0) start asking me for a password countless times and this
>>> make the connection useless.
>>>
>>> Any ideas to solve this problem?
>> I didn't get exactly which password you're talking about.
>> How are you trying to connect to the virtual machine? Is it ssh? If
>> yes, it may help you a bit:
>> http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/
>> If not, please, give more details.
>>
>> Best Regards,
>> -- 
>> Fabiano Fidêncio
>>
> 
> 
> 
> -- 
> ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti
> i dettagli Clicca qui
> http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f
> 
> 
> Sponsor:
> Soluzioni di email hosting per tutte le esigenze: dalle caselle gratuite a
> quelle professionali su piattaforma Zimbra, da quelle su proprio dominio a
> quelle certificate PEC. Confronta le soluzioni
> Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13325&d=16-2
> 
> ___
> virt-tools-list mailing list
> virt-tools-list@redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 02/08/2016 09:23 AM, Roman Kagan wrote:
> On Sat, Feb 06, 2016 at 06:20:42PM -0500, Cole Robinson wrote:
>> Sorry for the delay, been caught up in other stuff. I'll be focusing on
>> virtio-win stuff this coming week though
>>
>> I've committed these patches now. I added a few commits on top to make my
>> pylint[1] setup happy. No functional changes.
> 
> Great, thanks.
> I've accumulated a couple of fixes and enhancements in the meantime;
> I'll rebase and post them soon.
> 

So I'm full of crap and didn't actually touch virtio-win after sending that
mail, except trying to page this stuff back into memory. But it's my main
priority for the next bit of time.

>> I'm realizing now that the input bits to make-driver-dir.py
>> (virtio-win/qxl/qemu-ga windows builders from RH's internal build system)
>> aren't published anywhere so there isn't any way for you to reproduce the 
>> full
>> workflow for the public RPM. I'll work on getting those mirrored on
>> fedorapeople.org
> 
> Actually we started putting together our stuff, too, and encountered a
> number of issues I'd be interested to discuss.
> 

Can I ask what you plan to do with virtio-win RPM/ISO on your side? I'm trying
to spec out in my head all the bits that need to change, so understanding what
you're needs are will help my get things straight.

Are you just interested in extending the RHEL RPM, or the public one as well?
What types of bits are you adding? drivers, agents, etc

> 1) since the drivers can only be built on a Windows machine, there's a
>need to define the artifact(s) produced on a Windows machine and used
>as source(s) for rpmbuild on a Linux machine (koji).
> 
>We thought the most natural responsibility split (as applied to
>kvm-guest-drivers-windows) is to collect the stuff in "Install"
>subdirectories of every driver upon buildAll.bat execution in a
>single zip archive and use it as that artifact; the rest will be
>taken care of from under rpmbuild on a Linux machine.  One benefit is
>that it's going to be easy to intervene manually, e.g.  when doing
>signatures or whatever else.
> 
>This differs from what's currently in virtio-win srpm where the
>drivers are received in a tarball whose contents was obviously
>subject to certain manipulations after building on Windows.
> 

I'm not really familiar with the windows build process, so I'm not sure I
follow all of that. But the idea of pushing some of this rework down into the
kvm-guest-drivers-windows build infrastructure sounds like a good one to me,
since as you say that's the root source.

Regarding handling everything in rpmbuild, I'm not entirely sure how I feel.
Doing all the processing at rpmbuild time is probably okay as long as the
logic doesn't live entirely in the .spec file, and exists as external scripts
that can be tested independently of actually triggering 'rpmbuild'. Then say
virtio-win-pkg-scripts-gitXXX.tar.gz should just be about SOURCE in the spec
file. That would certainly streamline the process a bit and make it more clear
exactly what is going on.

Though on the RHEL side that will be a bit difficult, because the shipped
drivers are not composed of output from a single virtio-win build, but from
_many_ virtio-win builds.

For example, the latest winxp viostor WHQL submission might have used drivers
from internal build virtio-win-prewhql-26, and the latest win7 vioser WHQL
submission may have used bits from virtio-win-prewhql-52.

Now a new internal build pops up, virtio-win-prewhql-78. It's used to feed
win10 WHQL balloon submission. That build may ship have a newer winxp viostor
driver and a newer win7 vioser driver. But we aren't going to ship them,
because we are tied to the content that was used for the last WHQL submission.

Basically we have an internal git repo that tracks all whql submissions, their
associated prewhql input (which is raw kvm-guest-windows-drivers build
output), and we use the mappings to create a frankenstein symlink tree that
matches the driver layout you see on the virtio-win iso, or from upstream
make-driver-dir.py output. The public and RHEL build process then sync's up
the rest of the way.

So not sure how to handle that in rpmbuild without jumping through more hoops.

That said, a fix to sync up the processes a bit more is to generate a symlink
tree that matches the same layout as the kvm-guest-windows-drivers build
output. Then the public and RHEL build processes would be identical, except
for RHEL's prep step of splicing in the WHQL output.

> 
> 2) build scripts for kvm-guest-drivers-windows (haven't checked qxl yet)
>don't adhere to the conventions assumed by 

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 02/08/2016 11:07 AM, Roman Kagan wrote:
> On Mon, Feb 08, 2016 at 12:35:21PM +0100, Christophe Fergeau wrote:
>> For what it's worth, I've had success building (did not test) qemu-ga
>> with mingw using the attached spec file.
> 
> We build it in a similar way and use it in our testing for some time.
> 
> Are you planning to split it out of virtio-win somehow?
> 

I think Christophe was experimenting with building qemu-ga for integration
into spice-guest-tools.exe

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] QEMU/KVM and ssh

[Cole Robinson]

On 02/18/2016 05:59 AM, Ron Yorston wrote:
> I'm using virt-manager on Fedora 23.  When I start it I get an
> 'Authentication Required' prompt and have to enter a password.  If I
> shut it down and restart it I'm prompted again.  Fair enough.
> 
> I also have a connection to a remote host with a qemu+ssh:// URI.  When I
> activate this connection I'm prompted for the passphrase for my ssh key.
> Again, fair enough.
> 
> However, if I shut down and restart virt-manager then reactivate the
> remote connection I'm not prompted for the passphrase.  I don't have
> an ssh-agent.
> 
> What is remembering my credentials?  And how do I stop it from doing that?

Not virt-manager. If you are using gnome-shell, it has an integrated
ssh-agent. If the password dialog that pops up has your desktop themeing
that's probably the case, otherwise it will be a plain window like
openssh-askpass presents

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 02/18/2016 12:51 PM, Roman Kagan wrote:
> On Wed, Feb 17, 2016 at 06:11:54PM -0500, Cole Robinson wrote:
>> On 02/08/2016 11:07 AM, Roman Kagan wrote:
>>> On Mon, Feb 08, 2016 at 12:35:21PM +0100, Christophe Fergeau wrote:
>>>> For what it's worth, I've had success building (did not test) qemu-ga
>>>> with mingw using the attached spec file.
>>>
>>> We build it in a similar way and use it in our testing for some time.
>>>
>>> Are you planning to split it out of virtio-win somehow?
>>>
>>
>> I think Christophe was experimenting with building qemu-ga for integration
>> into spice-guest-tools.exe
> 
> I must admit I didn't know about spice-guest-tools.exe.  AFAICS from
> http://www.spice-space.org/download.html it's yet another means to bring
> the stuff from virtio-win into the guest, is it?  If so how is it synced
> with virtio-win?
> 

Yes that's one of the things we have discussed getting on the .iso at some
point, or doing nightly builds. Right now I think Christophe just builds it
manually on occasion, I don't think it's automated. The build code is here:

https://cgit.freedesktop.org/~teuf/spice-nsis/

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 5/5] virt-manager: add opengl graphics option

[Cole Robinson]

On 02/18/2016 11:47 AM, Marc-André Lureau wrote:
> From: Marc-André Lureau 
> 
> Add a OpenGl checkbox to the Spice graphics option.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  ui/gfxdetails.ui  | 29 +
>  virtManager/details.py|  9 +++--
>  virtManager/domain.py |  5 -
>  virtManager/gfxdetails.py | 11 ---
>  4 files changed, 48 insertions(+), 6 deletions(-)



> diff --git a/virtManager/gfxdetails.py b/virtManager/gfxdetails.py
> index 0ae76c9..df54bbf 100644
> --- a/virtManager/gfxdetails.py
> +++ b/virtManager/gfxdetails.py
> @@ -35,6 +35,7 @@ class vmmGraphicsDetails(vmmGObjectUI):
>  "changed-type": (GObject.SignalFlags.RUN_FIRST, None, []),
>  "changed-address": (GObject.SignalFlags.RUN_FIRST, None, []),
>  "changed-keymap": (GObject.SignalFlags.RUN_FIRST, None, []),
> +"changed-opengl": (GObject.SignalFlags.RUN_FIRST, None, []),
>  }
>  
>  def __init__(self, vm, builder, topwin):
> @@ -54,6 +55,7 @@ class vmmGraphicsDetails(vmmGObjectUI):
>  "on_graphics_tlsport_changed": lambda ignore: 
> self.emit("changed-tlsport"),
>  "on_graphics_port_changed": lambda ignore: 
> self.emit("changed-port"),
>  "on_graphics_keymap_changed": lambda ignore: 
> self.emit("changed-keymap"),
> +"on_graphics_opengl_toggled": lambda ignore: 
> self.emit("changed-opengl"),
>  })
>  
>  self._init_ui()
> @@ -143,7 +145,9 @@ class vmmGraphicsDetails(vmmGObjectUI):
>  if not self.widget("graphics-password-chk").get_active():
>  passwd = None
>  
> -return gtype, port, tlsport, addr, passwd, keymap
> +gl = self.widget("graphics-opengl").get_active()
> +
> +return gtype, port, tlsport, addr, passwd, keymap, gl
>  
>  def set_dev(self, gfx):
>  self.reset_state()
> @@ -188,6 +192,7 @@ class vmmGraphicsDetails(vmmGObjectUI):
>  
>  if is_spice:
>  set_port("graphics-tlsport", gfx.tlsPort)
> +self.widget("graphics-opengl").set_active(gfx.gl == "yes")
> 

It shouldn't return a 'yes' value here, since virtinst is_onoff will convert
to bool. So just gfx.gl I think

Otherwise looks fine

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 4/5] virt-manager: connect with openGraphicsFD

[Cole Robinson]

On 02/18/2016 11:47 AM, Marc-André Lureau wrote:
> From: Marc-André Lureau 
> 
> This allows to connect to VM without any listening socket.
> 
> Furthermore, since it uses unix socket, spice can use virgl locally
> with texture sharing. This effectively enables spice-gtk to display
> local virgl rendering.
> 

Can you expand on this a bit more? Does this require https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 4/5] virt-manager: connect with openGraphicsFD

[Cole Robinson]

On 02/22/2016 10:10 AM, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Feb 18, 2016 at 8:11 PM, Cole Robinson  wrote:
>> Can you expand on this a bit more? Does this require > ...  value to be specified by the user or something? Or will it enable gl 
>> even
>> for listen=127.0.0.1 for example
> 
> It doesn't require any Spice listening socket, the fd passing is done
> through libvirt.
> 

Okay, I'll poke at this to understand it better, then we can push this patch
separate from the spice bits since it's useful for vnc+unix socket as well

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts] cpdrivers: accept unsigned binaries

[Cole Robinson]

On 02/20/2016 08:57 AM, Roman Kagan wrote:
> PE binaries included in the driver package (.sys, .dll, etc) may contain
> no internal signatures; in that case their digest in the catalog is
> calculated till the end of the file.
> 
> Signed-off-by: Roman Kagan 
> ---
>  util/cpdrivers.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/util/cpdrivers.py b/util/cpdrivers.py
> index 305b3ae..f4b1d6e 100644
> --- a/util/cpdrivers.py
> +++ b/util/cpdrivers.py
> @@ -65,6 +65,8 @@ def calcPEHash(data, hashobj):
>  0x20b: 168 # PE32+
>  }[pemagic]
>  sec, seclen = struct.unpack_from("2I", data, secdir)
> +if sec == 0:
> +sec = len(data)
>  # signature is always the tail part
>  assert sec + seclen == len(data)
>  
> 

Thanks, pushed now

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] virt-convert: decompress the .gz files before converting

[Cole Robinson]

On 02/23/2016 09:55 PM, Lin Ma wrote:
> The OVF specification v1.1.0(page 15) indicates that "Each file
> referenced by a File element may be compressed using gzip
> (see RFC1952)."
> 
> In this case the .gz files should be decompressed first before
> converting through qemu-img.
> 
> Signed-off-by: Lin Ma 
> ---
>  virtconv/formats.py | 10 ++
>  1 file changed, 10 insertions(+)
>

Thanks for the patch! Comments below

> diff --git a/virtconv/formats.py b/virtconv/formats.py
> index a7f88cb..ab37e10 100644
> --- a/virtconv/formats.py
> +++ b/virtconv/formats.py
> @@ -275,12 +275,22 @@ class VirtConverter(object):
>  raise RuntimeError(_("None of %s tools found.") % binnames)
>  
>  base = os.path.basename(absin)
> +ext = os.path.splitext(base)[1]
> +if (ext and ext[1:] == "gz"):
> +if not find_executable("gzip"):
> +raise RuntimeError("'gzip' is needed to decompress the file, 
> "
> +"but not found.")
> +decompress_cmd = ["gzip", "-d", absin]
> +base = os.path.splitext(base)[0]
> +absin = absin[0:-3]
> +self.print_cb("Running %s" % " ".join(decompress_cmd))
>  cmd = [executable, "convert", "-O", disk_format, base, absout]
>  self.print_cb("Running %s" % " ".join(cmd))
>  if dry:
>  return
>  
>  cmd[4] = absin
> +_run_cmd(decompress_cmd)
>  _run_cmd(cmd)
>

decompress_cmd is conditionally defined. you'll need to set decompress_cmd =
None first, and have this _run_cmd dependent on that.

Also a test case that exercises that code path would be appreciated.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] UEFI and xen

[Cole Robinson]

On 03/01/2016 11:21 AM, Clair Grant wrote:
> Virt-install on kvm provides boot loader options for UEFI rather than BIOS. 
> There does not seem to be a similar option in virt-install on xen. Is there 
> another means for being UEFI-based on xen?
> 

Personally I have no idea what the state of xen + uefi support is.

>From virt-install/virt-manager perspective, to make '--boot uefi' work we
require a libvirt capabilities reporting API that isn't yet supported by the
xen driver.

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] UEFI and xen

[Cole Robinson]

On 03/01/2016 01:18 PM, Jim Fehlig wrote:
> Cole Robinson wrote:
>> On 03/01/2016 11:21 AM, Clair Grant wrote:
>>> Virt-install on kvm provides boot loader options for UEFI rather than BIOS. 
>>> There does not seem to be a similar option in virt-install on xen. Is there 
>>> another means for being UEFI-based on xen?
>>>
>>
>> Personally I have no idea what the state of xen + uefi support is.
> 
> Xen+uefi works at the xen tools level (xl/libxl), but not yet via libvirt.
> 
>> >From virt-install/virt-manager perspective, to make '--boot uefi' work we
>> require a libvirt capabilities reporting API that isn't yet supported by the
>> xen driver.
> 
> I guess you mean connectGetDomainCapabilities? The xen drivers support
> connectGetCapabilities but currently lack connectGetDomainCapabilities.
> 

Yes, getDomainCapabilities. Libvirt uses that to advertise what uefi roms are
on the host, so we can make --boot uefi work automagically. Rom paths can
still be manually specified though

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 2/2 V2] test: Add a test for converting ovf+compressed files.

[Cole Robinson]

On 03/04/2016 02:58 AM, Lin Ma wrote:
> Signed-off-by: Lin Ma 
> ---
>  I'm not familiar with how to write a test, If there is anything wrong,
>  Please forgive me and let me know.
> 
>  .../ovf2libvirt_gzip_ovf_directory.libvirt |  79 ++
>  .../ovf_input/ovf_directory/test_gzip.ovf  | 121 
> +
>  .../ovf_directory/test_gzip.ovf-disk1.vmdk.gz  | Bin 0 -> 114 bytes
>  3 files changed, 200 insertions(+)
>  create mode 100644 
> tests/virtconv-files/libvirt_output/ovf2libvirt_gzip_ovf_directory.libvirt
>  create mode 100644 tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf
>  create mode 100644 
> tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf-disk1.vmdk.gz
> 
> diff --git 
> a/tests/virtconv-files/libvirt_output/ovf2libvirt_gzip_ovf_directory.libvirt 
> b/tests/virtconv-files/libvirt_output/ovf2libvirt_gzip_ovf_directory.libvirt
> new file mode 100644
> index 000..b74f415
> --- /dev/null
> +++ 
> b/tests/virtconv-files/libvirt_output/ovf2libvirt_gzip_ovf_directory.libvirt
> @@ -0,0 +1,79 @@
> +
> +  test_gzip.ovf
> +  ----
> +  4194304
> +  4194304
> +  1
> +  
> +/machine
> +  
> +  
> +hvm
> +
> +  
> +  
> +
> +
> +
> +  
> +  
> +Haswell-noTSX
> +  
> +  
> +
> +
> +
> +  
> +  destroy
> +  restart
> +  restart
> +  
> +
> +
> +  
> +  
> +/usr/bin/qemu-kvm
> +
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +
> +
> +  
> +
> +
> +  
> +
> +
> +  
> +
> +
> +  
> +  
> +  
> +
> +
> +
> +  
> +
> +
> +
> +  
> +
> +
> +
> +  
> +
> +
> +
> +  
> +
> +
> +
> +Copying test_gzip.ovf-disk1.vmdk to 
> /var/lib/libvirt/images/test_gzip.ovf-disk1.vmdk.raw
> diff --git a/tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf 
> b/tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf
> new file mode 100644
> index 000..a6fdfff
> --- /dev/null
> +++ b/tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf
> @@ -0,0 +1,121 @@
> +
> +
> + xmlns="http://schemas.dmtf.org/ovf/envelope/1"; 
> xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common"; 
> xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"; 
> xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData";
>  xmlns:vmw="http://www.vmware.com/schema/ovf"; 
> xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> +  
> + ovf:id="file1" ovf:size="848847459"/>
> +  
> +  
> +Virtual disk information
> + ovf:diskId="vmdisk1" ovf:fileRef="file1" 
> ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized";
>  ovf:populatedSize="1587937280"/>
> +  
> +  
> +The list of logical networks
> +
> +  The bridged network
> +
> +  
> +  
> +A virtual machine
> +test_gzip.ovf
> + vmw:osType="sles11_64Guest">
> +  The kind of installed guest operating system
> +
> +
> +  Virtual hardware requirements
> +  
> +Virtual Hardware Family
> +0
> +
> test_gzip.ovf
> +vmx-04
> +  
> +  
> +hertz * 10^6
> +Number of Virtual CPUs
> +1 virtual CPU(s)
> +1
> +3
> +1
> +  
> +  
> +byte * 2^20
> +Memory Size
> +4096MB of memory
> +2
> +4
> +4096
> +  
> +  
> +0
> +USB Controller (EHCI)
> +usb
> +3
> +vmware.usb.ehci
> +23
> + vmw:value="false"/>
> +  
> +  
> +0
> +SCSI Controller
> +scsiController0
> +4
> +lsilogic
> +6
> +  
> +  
> +0
> +IDE Controller
> +ideController0
> +5
> +5
> +  
> +  
> +0
> +false
> +Floppy Drive
> +floppy0
> +6
> +14
> +  
> +  
> +0
> +false
> +cdrom1
> +7
> +5
> +15
> +  
> +  
> +0
> +disk1
> +ovf:/disk/vmdisk1
> +8
> +4
> +17
> +  
> +  
> +2
> +true
> +bridged
> +E1000 ethernet adapter on 
> "bridged"
> +ethernet0
> +9
> +E1000
> +10
> +  
> +  
> +false
> +video
> +10
> +24
> +  
> +  
> +false
> +vmci
> +11
> +vmware.vmci
> +1
> +  
> +   vmw:value="true"/>
> +
> +  
> +
> diff --git 
> a/tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf-disk1.vmdk.gz 
> b/tests/virtconv-files/ovf_input/ovf_directory/test_gzip.ovf-disk1.vmdk.gz
> new file mode 100644
> ind

Re: [virt-tools-list] can't set a mac address when creating guest.

[Cole Robinson]

On 03/06/2016 01:53 AM, leandro maciel wrote:
> Hello,
> 
> I was using virt-manager to create and configure machines on a CentOS 7.1 host
> and when I was able to set the MAC address while creating the guests.
> 
> My CentOS 7.1 had a problem and I installed CentOS 7.2 on another machine and
> started configuring qemu/kvm and virt-manager again, but this time I can't set
> the MAC Address while creating the guest, there is no field for that on the
> advanced options and I also can't change the MAC Address on the machine 
> details.
> 

The UI changed a bit. You need to select 'Customize before install' on the
last page of the 'New VM' wizard, then you can change the the MAC address on
the network's details page.

- Cole


___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Migration of VMms using virt-manager

[Cole Robinson]

On 03/07/2016 11:53 PM, Renju M wrote:
> Hello,
> 
> I am using virt-manager for managing virtual machines for my project. During
> migration of a VM using virt-manager, what exactly gets migrated? Is it the
> XML description of VM saying what all resources will be required at the
> destination for VM to run?
> 

For a traditional migration, the VMs runtime memory contents are transfered,
so the VM continues to run uninterrupted on the new physical machine. By
default virt-manager will also move the XML (undefine on the source host,
define on the new host). The disk contents however are expected to be
accessible to both physical hosts, like over NFS or similar.

- Cole


___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] new home for vhostmd

[Cole Robinson]

On 03/09/2016 05:58 PM, Jim Fehlig wrote:
> Hi All,
> 
> I had once again nearly forgot about vhostmd whenI received a mail from
> Michael-John Turner asking about packaging it for Debian. He was looking for 
> the
> canonical source, which was on the now defunct gitorious. Sadly, I never moved
> the code togithub, gitlab, other hosting service that may die in the future. 
> It
> is still available via the readonly mirror
> 
> https://gitorious.org/vhostmd/vhostmd.git/
> 
> vhos...@opensuse.org was used as a mail list for vhostmd discussions, but with
> no activity in years the list was apparently removed. In my reply to
> Michael-John, I received the following response when cc'ing 
> vhos...@opensuse.org:
> 
>: Command died with status 1:
>   "/usr/bin/mlmmj-recieve -L /var/spool/mlmmj-gone/gone/"
> 
> Since vhostmd is one of many virt-tools, I'm writing here to see if there is 
> any
> interest in including vhostmd in virt-tools discussions. Saying vhostmd 
> traffic
> is light is an understatement, so I don't think it would burden the list. Like
> virt-manager, the code could be moved to github and its README updated to 
> point
> to virt-tools-list for "comments / suggestions / patches".
> 
> Thanks for you comments.
> 

Sounds good to me

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

[Cole Robinson]

On 02/29/2016 09:16 AM, Yedidyah Bar David wrote:
> On Mon, Feb 29, 2016 at 3:00 PM, Christophe Fergeau  
> wrote:
>> On Thu, Feb 18, 2016 at 01:51:25PM -0500, Cole Robinson wrote:
>>> On 02/18/2016 12:51 PM, Roman Kagan wrote:
>>>> On Wed, Feb 17, 2016 at 06:11:54PM -0500, Cole Robinson wrote:
>>>>> On 02/08/2016 11:07 AM, Roman Kagan wrote:
>>>>>> On Mon, Feb 08, 2016 at 12:35:21PM +0100, Christophe Fergeau wrote:
>>>>>>> For what it's worth, I've had success building (did not test) qemu-ga
>>>>>>> with mingw using the attached spec file.
>>>>>>
>>>>>> We build it in a similar way and use it in our testing for some time.
>>>>>>
>>>>>> Are you planning to split it out of virtio-win somehow?
>>>>>>
>>>>>
>>>>> I think Christophe was experimenting with building qemu-ga for integration
>>>>> into spice-guest-tools.exe
>>>>
>>>> I must admit I didn't know about spice-guest-tools.exe.  AFAICS from
>>>> http://www.spice-space.org/download.html it's yet another means to bring
>>>> the stuff from virtio-win into the guest, is it?  If so how is it synced
>>>> with virtio-win?
>>>>
>>>
>>> Yes that's one of the things we have discussed getting on the .iso at some
>>> point, or doing nightly builds. Right now I think Christophe just builds it
>>> manually on occasion, I don't think it's automated. The build code is here:
>>>
>>> https://cgit.freedesktop.org/~teuf/spice-nsis/
>>
>> Didi (cc'ed) has been doing some great work in automating this as they
>> wanted to use this (+ their ovirt agent) for oVirt guests.  Current
>> upstream repository is
>> https://cgit.freedesktop.org/spice/spice-nsis/
> 
> In ovirt we have this manually-synced at:
> 
> https://gerrit.ovirt.org/gitweb?p=ovirt-wgt.git;a=summary
> 
> See this if you want to work with this gerrit instance:
> 
> http://www.ovirt.org/develop/dev-process/working-with-gerrit/
> 
> "manually" means that we sometimes do reviews there, but only actually
> merge patches after they were merged in spice-nsis, with same commit
> hashes.
> 
>>
>> There now is a Makefile extracting the drivers we need from the
>> virtio-win ISO, which means going through a few steps we'd rather avoid:
>> https://cgit.freedesktop.org/spice/spice-nsis/tree/Makefile#n106
> 
> See also: https://bugzilla.redhat.com/show_bug.cgi?id=1167941
> 
>>
>> Then we have a .spec file which can generate the installer from a
>> virtio-win rpm, vdagent rpm, qxl rpm.
>>
>> In other words, the whole build process of spice-nsis is now much more
>> saner and automatable/automated. Not having to extract the files
>> manually from virtio-win.iso would indeed be even better, and making
>> all these bits of pieces (mingw-vdagent, an installer, ..) available
>> from a single place would indeed be even better.
>>
>> Christophe
> 
> Thanks to Sandro's recent work, jenkins builds are fully automated
> now. E.g., we recently posted this to spice-devel:
> 
> https://lists.freedesktop.org/archives/spice-devel/2016-February/026436.html
> 
> We also pushed it to gerrit:
> 
> https://gerrit.ovirt.org/53326
> 
> At the bottom you can see links to jenkins builds inside the comments.
> 
> I do not think I am subscribed to virt-tools-list, sorry.
> 

Thanks for the info! (just responding so this shows up in virt-tools-list
archives for posterity)

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH v2 5/5] virt-manager: add opengl graphics option

[Cole Robinson]

On 03/04/2016 06:31 AM, Marc-André Lureau wrote:
> From: Marc-André Lureau 
> 
> Add a OpenGl checkbox to the Spice graphics option.
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  ui/gfxdetails.ui  | 29 +
>  virtManager/details.py|  9 +++--
>  virtManager/domain.py |  5 -
>  virtManager/gfxdetails.py | 11 ---
>  4 files changed, 48 insertions(+), 6 deletions(-)

I pushed 1-4, thanks!

What does enabling just gl for spice give us, without virtio-gpu + 3daccel?
Any error scenarios or weirdness?

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH 1/2 V3] virt-convert: decompress the .gz files before converting

[Cole Robinson]

On 03/07/2016 05:39 AM, Lin Ma wrote:
> The OVF specification v1.1.0(page 15) indicates that "Each file
> referenced by a File element may be compressed using gzip
> (see RFC1952)."
> 
> In this case the .gz files should be decompressed first before
> converting through qemu-img.
> 
> Signed-off-by: Lin Ma 
> ---
>  virtconv/formats.py | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/virtconv/formats.py b/virtconv/formats.py
> index a7f88cb..6fa6215 100644
> --- a/virtconv/formats.py
> +++ b/virtconv/formats.py
> @@ -263,6 +263,8 @@ class VirtConverter(object):
>  """
>  binnames = ["qemu-img", "kvm-img"]
>  
> +decompress_cmd = None
> +
>  if _is_test():
>  executable = "/usr/bin/qemu-img"
>  else:
> @@ -275,12 +277,23 @@ class VirtConverter(object):
>  raise RuntimeError(_("None of %s tools found.") % binnames)
>  
>  base = os.path.basename(absin)
> +ext = os.path.splitext(base)[1]
> +if (ext and ext[1:] == "gz"):
> +if not find_executable("gzip"):
> +raise RuntimeError("'gzip' is needed to decompress the file, 
> "
> +"but not found.")
> +decompress_cmd = ["gzip", "-d", absin]
> +base = os.path.splitext(base)[0]
> +absin = absin[0:-3]
> +self.print_cb("Running %s" % " ".join(decompress_cmd))
>  cmd = [executable, "convert", "-O", disk_format, base, absout]
>  self.print_cb("Running %s" % " ".join(cmd))
>  if dry:
>  return
>  
>  cmd[4] = absin
> +if decompress_cmd is not None:
> +_run_cmd(decompress_cmd)
>  _run_cmd(cmd)
>  
>  def convert_disks(self, disk_format, destdir=None, dry=False):
> 

python setup.py test --coverage, then coverage annotate -d covdir, then look
in covdir/virtconv_formats.py,cover:

> base = os.path.basename(absin)
> ext = os.path.splitext(base)[1]
> if (ext and ext[1:] == "gz"):
! if not find_executable("gzip"):
! raise RuntimeError("'gzip' is needed to decompress the file, "
! "but not found.")
! decompress_cmd = ["gzip", "-d", absin]
! base = os.path.splitext(base)[0]
! absin = absin[0:-3]
! self.print_cb("Running %s" % " ".join(decompress_cmd))
> cmd = [executable, "convert", "-O", disk_format, base, absout]
> self.print_cb("Running %s" % " ".join(cmd))
> if dry:
>


That means the test suite still isn't testing the newly added code, so
something is missing from the test case

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list